operators.md

Operators

Full operator catalog, promotion criteria, and corpus-validation status. See the README for the short "what's enabled by default" summary.

An operator earns defaultEnabled by evidence, not by being interesting:

• it corresponds to a documented real fault pattern
• it has positive and negative syntax fixtures
• ≥99% compile success rate
• zero phantom mutants
• few trivial or duplicate mutants
• isolated and schemata execution agree
• validated on multiple real projects
• its diff is understandable to the developer who has to act on it

Operator	Profile	Confidence	Notes
swift.core.bool-literal-inversion	conservative	high	true ↔ false
swift.core.relational-operator-replacement	conservative	high	boundary shift + negation, e.g. < → <=, >=
swift.core.logical-connector-replacement	conservative	high	&& ↔ ||
swift.core.ternary-branch-swap	conservative — validated	high	a ? b : c → a ? c : b; preserves comments/trivia around the condition and both branches. Always compile-viable; corpus-measured on two real projects at a consistent, modest 13.3% → 20.8% → 26.5% kill rate — never contradicted, but both measured projects share a SwiftUI-heavy shape, so whether the modest yield is inherent or shape-specific remains open (deferred, non-blocking)
swift.core.unary-not-removal	default — validated	medium	!x → x; never assumes a multi-! token (!!x) is stacked built-in negation, since it could be a user-defined operator. Corpus-measured on two real projects at a consistently healthy 40.0% → 47.4% → 45.2% kill rate — no signal-density concern in either
swift.core.return-value-replacement	default — validated	medium	restricted to explicit returns whose neutral replacement the syntax alone proves safe; excludes equivalent spellings (0x0, nil as T?, Optional<T>.none, an empty raw string, ...) by value/structure, not text comparison. Corpus-measured on two real projects at a healthy and improving 29.4% → 30.4% → 71.4% kill rate
swift.core.nil-coalescing-fallback	experimental	medium	a ?? b → b; a surviving mutant means the suite never proved a non-nil left-hand value is preferred over the fallback, not that the nil path is untested. Always compile-viable, but a real-project corpus run showed it alone occupying half a 100-mutant sample with 8.3% kill rate on buildable mutants, mostly re-stating the same low-value "defensive ?? fallback, never tested against a non-nil value" gap — demoted for signal density, not compile safety
swift.core.arithmetic-operator-replacement	experimental	medium	+ ↔ -, * ↔ /; no symbol resolution, and Swift's arithmetic protocols do not guarantee a matched pair (Numeric has no /) — confirmed to produce real compile failures against representative fixtures. A targeted 50-mutant corpus run against a real project measured 0 unviable (this codebase's arithmetic usage didn't happen to hit those patterns — not evidence the fixture risk is false). The same run originally reported a much larger flaky/infrastructure-failure count than any other operator; most of that turned out to be a batch-timeout attribution bug, since fixed — 2 genuine, reproducible hangs remain, clustered in loop/index-arithmetic code
swift.core.assignment-operator-replacement	experimental	medium	+= ↔ -=, *= ↔ /=; same compile-viability gap as arithmetic replacement one syntactic level up. A targeted 50-mutant corpus run against a real project measured 0 unviable and a healthy 37.5% kill rate, without arithmetic's instability pattern (1/50 flaky, no timeouts)
swift.core.else-clause-deletion	experimental	experimental	if a { X } else { Y } → if a { X }; only the trailing else/else if clause is ever removed, never the if branch or the condition, and discovery skips sites where deleting else would break Swift's exhaustiveness rules for an if/switch expression or the last statement of a non-Void body. Brand new — no Muter analogue and no real-project corpus measurement yet
swift.core.range-boundary-replacement	experimental	experimental	a..<b ↔ a...b; covers only the binary infix form. Not proven safe to compile (the two forms produce different concrete range types) or safe to run (..< → ... can turn a valid upper-bound-exclusive index into an out-of-bounds access) by default. Brand new — no real-project corpus measurement yet
swift.core.side-effect-call-removal	experimental	experimental	Muter's RemoveSideEffects, generalized: deletes a standalone function/method call statement whose return value is discarded — logging, caching, a UI update, cleanup. Never removes fatalError/preconditionFailure/exit/abort (unconditionally, any position — these are genuinely Never-returning and can be silently load-bearing for an enclosing function's reachability), the sole statement of a guard-else or switch case, an implicit-return body's sole statement, or anything inside a @ViewBuilder-style result-builder body. Configurable per-call exclusion (operators.sideEffectCallRemoval.excludeCalls) is what migrate --from-muter maps Muter's own excludeCalls onto. Brand new — no real-project corpus measurement yet

"validated" above means: corpus-measured on two real, independently-shaped projects, with a consistent (or consistently improving) kill rate and no disqualifying signal-density or compile-safety concern in either — closed as of v0.4 Trust Closure, Workstream C. "No disqualifying concern" is deliberate, not "no concern at all": ternary-branch-swap's validation carries one recorded, non-blocking caveat that is itself a modest signal-density observation — both measured projects share a SwiftUI-heavy shape, so whether its modest (13–27%) kill rate is inherent to the mutation or an artifact of that shared shape is still open. It was not judged disqualifying because the rate never reversed across three measurements and has a specific, plausible, already-identified explanation, unlike nil-coalescing-fallback's own contradicted (not merely low) measurement. Resolving the remaining shape question needs a non-UI-heavy project (e.g. a macOS Swift Package) and is deferred future corpus work, not a v0.4 blocker. Assignment-operator-replacement has been corpus-measured on only one real project so far. Else-clause-deletion, range-boundary-replacement and side-effect-call-removal are new and have not yet been corpus-measured on any project. Full methodology and results (internal, not part of this public repo): Research/corpus-validation/.

Arithmetic, assignment, else-clause-deletion, range-boundary-replacement and side-effect-call-removal are reachable via the experimental profile or an explicit operators.enable entry, not by default — see Research/operator-catalog/README.md (internal, not part of this public repo) for the measured compile-viability evidence and what promoting them to default would require. Nil-coalescing fallback is reachable the same way, for a different reason: see Research/operator-catalog/README.md (internal, not part of this public repo) for the corpus signal-density evidence — a second real project's measurement did not reproduce the first project's low kill rate, an unresolved discrepancy, not a reversal of the demotion — and what re-promoting it would require.

Schemata execution: per-operator promotion

One shared build embeds every mutation; a verifier-only trust chain (per-image build receipts, binary runtime protocol, confirmation parity with isolated mode) decides every verdict; per-operator, gated by a lowerer registry. All six default/conservative operators (bool-literal-inversion, relational-operator-replacement, logical-connector-replacement, unary-not-removal, return-value-replacement, ternary-branch-swap) are embeddable today, each promoted only after its own zero-disagreement isolated-vs-schemata differential proof on real projects (the first two operators' own formal measurement, +3–8% wall-time over isolated mode, is internal and not part of this public repo; later promotions carried the same correctness gate, not necessarily the same speedup — see each operator's own promotion history). Every other (experimental-only) operator automatically falls back to isolated mode.

Apple-specific operators

Apple-specific operators (lifecycle, cancellation, continuation, persistence, SwiftUI, accessibility) must be derived from a classified corpus of real bug-fix commits in shipping open-source apps — the method MDroid+ used for Android — not from plausible-sounding guesses. Every one of the six target fault families (lifecycle, cancellation, continuation, persistence, SwiftUI, accessibility) has reached a completed research disposition — validated operator, experimental operator, or an explicitly deferred/rejected candidate with its reasoning on record; further corpus work, additional candidate operators, and promotion evidence remain ongoing. The fault taxonomy and per-category corpus work lives at Research/fault-taxonomy/ (internal, not part of this public repo).

Candidates that clear that bar land here, at defaultEnabled: false and whatever confidence their own corpus evidence supports — never defaultEnabled: true on this catalog's evidence alone. See Research/fault-taxonomy/README.md for the six-category research disposition and Research/phase5-closure-2026-09/README.md for the frozen operator inventory this table reflects:

Operator	Profile	Confidence	Notes
apple.concurrency.continuation-resume-removal	experimental	medium	Removes a .resume()/.resume(returning:)/.resume(throwing:)/.resume(with:) call when it is a bare statement. Grounded in a classified corpus of 5 independently-verified bug-fix commits (of 15 total classified, across apple/swift-async-algorithms, apple/swift-nio, pointfreeco/swift-composable-architecture, pointfreeco/swift-concurrency-extras) where a continuation was never resumed on some code path — see the fault-taxonomy research (internal, not part of this public repo) for the full corpus. Excludes the sole statement of a switch case (Swift requires ≥1 executable statement there), the sole statement of an implicit-parameter ($0) closure (emptying it leaves an unused-parameter compile error), and the last remaining resume-family call reachable inside a withCheckedContinuation/withCheckedThrowingContinuation/withUnsafeContinuation/withUnsafeThrowingContinuation trailing closure (removing it can break that function's generic-parameter inference — "generic parameter 'T' could not be inferred") — all three confirmed against a real swiftc compile, not assumed; if/catch bodies do not need the switch-case exclusion (both compile fine empty), correcting an overcautious claim in the original research document. Corpus-measured 2026-09 on apple/swift-async-algorithms (75/75 candidates: 34 killed, 19 survived, 18 noCoverage, 4 infrastructureFailure — root-caused to a trait-gated file compiled out under the default build config, not an operator defect) and apple/swift-nio (full 38/38 candidates run to completion: 18 killed, 1 survived, 12 noCoverage, 5 infrastructureFailure — root-caused to a legacy duplicate target never linked into the configured test targets, not an operator defect). The swift-nio run found and closed a real compile-safety gap (2 unviable results, the continuation-creating-closure shape above) before this promotion — re-verified at 0 unviable against the same real corpus once fixed; the fix's own adversarial review found and closed a second gap in the first attempt (a same-named resume() call on an unrelated receiver, e.g. DispatchSourceTimer, could otherwise mask the continuation's own sole call). Zero integrity violations on either project. verifiedTimeout — not killed/survived — was confirmed as the dominant outcome for covered candidates on both projects (21/34 kills on swift-async-algorithms, 18/18, i.e. 100%, on swift-nio), exactly as this operator's own doc comment predicted; each one costs minutes, not seconds. Promoted confidence to medium on this evidence — validated opt-in, not default: the cost profile, not compile safety or signal quality, is why defaultEnabled stays false. schemataEligible: false remains, pending a separate isolated-vs-schemata differential proof. Full evidence, exact SHAs and toolchains: Research/corpus-validation/continuation-resume-removal-2026-09/.
apple.persistence.required-decode-introduction	experimental	medium	Replaces the canonical backward-compatible-decode shape try container.decodeIfPresent(T.self, forKey: key) ?? fallback with try container.decode(T.self, forKey: key) — the accidental regression that turns a schema-evolution-safe optional field back into a required one. Grounded in Le Chariot (Scxttk/lechariot-app PR #40, which explicitly mutation-tested this exact inverse change by hand and observed old fixtures fail with keyNotFound) and wikimedia/wikipedia-ios's own decodeIfPresent(...) ?? default compatibility handling. Matches only the canonical two-argument shape (an unlabeled <Type>.self first argument, a forKey:-labeled second argument) under a plain try (excludes try?/try!) as the immediate left operand of ??; replaces the whole nil-coalescing expression, carrying the original call's two arguments over unmodified. Adversarial compile-safety review (verified against real swiftc, not assumed) found no hazard analogous to the continuation operator's generic-inference gap: T is always pinned explicitly by T.self, and ??'s own type-checking already forces the fallback to unify with T before this operator ever sees the source — confirmed across a plain value type, an Optional-typed T, an array, a RawRepresentable enum, and a nested Decodable struct, all compiling both before and after the mutation. The one accepted, unmeasured risk: a custom, non-stdlib decodeIfPresent name-alike with no sibling decode(_:forKey:) would be a real (not merely low-value) compile failure — not found on either corpus project. Corpus-measured 2026-09 on segmentio/analytics-swift (14/14 candidates, all in one file: 2 killedByAssertion, 12 verifiedTimeout — root-caused to a real hang in that project's Analytics startup pipeline swallowing the thrown decode error inside an unbounded wait, not a harness artifact — 0 survived, 0 unviable) and amplitude/Amplitude-Swift (3/3 candidates: 2 killedByAssertion, 1 survived — a specific, well-explained single test gap, not a blind spot). Zero unviable/infrastructureFailure across both (17 candidates total); zero integrity violations. Promoted confidence to medium on this evidence — validated opt-in, not default: the verifiedTimeout-dominant cost profile on the harder corpus (not compile safety or signal quality) is why defaultEnabled stays false, the same reasoning apple.concurrency.continuation-resume-removal was kept opt-in for. schemataEligible: false — no schemata lowerer implemented for this operator. Full evidence, exact SHAs and toolchains: Research/corpus-validation/required-decode-introduction-2026-09/.
apple.concurrency.post-await-cancellation-guard-removal	experimental	experimental	Removes the canonical post-await cancellation guard guard !Task.isCancelled else { return } when it immediately follows a code-block item containing an await, so a cancelled task's stale result is published anyway. Grounded in zubair-io/Maple PR #3018 (MuiAvatar.loadPhoto(), MuiRemoteImageController.start(tiers:)) and whysasse/verso-app PR #375 (AddArticleView.save() and three sibling functions) — both real bug-fix PRs adding this exact three-part shape (await, then the guard, then code that must not run late). Matches only a single-condition guard whose condition is the direct negation of a bare Task.isCancelled and whose else body is a bare return, immediately after a preceding sibling item whose subtree contains an await — excludes compound conditions, optional-binding conditions, cleanup-before-return else bodies, if Task.isCancelled { return } (a different statement kind entirely), and a guard with no preceding item (cancelled-before-work-starts, a different fault). Needs none of the sibling operators' extra syntax-shape guards (never empties a block, never breaks generic inference, never a definite-initialization hazard) — confirmed directly against a real swiftc compile across five representative enclosing shapes (plain function, throwing function, for loop, switch case, Task { } closure), zero diagnostics before or after mutation. Corpus-measured 2026-09 on zubair-io/Maple's MapleUI package (full 5/5 candidates: 0 killed, 5 survived — each individually root-caused as a genuine test gap or a guard masked by an unmutated sibling guard, never a matcher defect) and a standalone fixture built to isolate that masking finding (disclosed as authored, not real-world evidence: 2/4 killed by assertion, both fast; 2/4 survived, reproducing the same masking relationship on purpose). Also found: a guard that is the first statement of a catch body (the real whysasse/verso-app PR's own repeated shape) is excluded by the "preceding item" rule, since a catch body's first item has no preceding sibling — a real, now-documented scope boundary. Zero unviable/infrastructureFailure/integrity violations across both corpora (9 candidates total). Promotion decision: remain experimental, not promoted to confidence: .medium — compile safety and matcher precision are both clean, but the one real project run showed 0/5 real kills, so "empirically useful real-world signal" (the bar the two operators above each cleared) was not met this round. Full evidence, the search performed for a second real corpus, and the adversarial review: Research/corpus-validation/post-await-cancellation-guard-removal-2026-09/.
apple.swiftui.task-id-removal	experimental	experimental	Removes the id: argument from .task(id:)/.task(id:priority:), so the view's async task never restarts when its identity-driving input changes. Grounded in zubair-io/Maple PR #3018's own BLOCKING finding: MuiRemoteImage's @StateObject controller captured tiers once at first init, and its .task { } had no id:, so SwiftUI reusing the view (List cells, record updates) with different tiers never updated the displayed image; fixed by .task(id: tiers.ordered.map(\.1)) { await controller.start(tiers: tiers) } — this operator mutates back to exactly that pre-fix state. Matches only id: alone or id: followed by priority:, in that exact order, on a call named task with a trailing closure — any other label, order, or argument count is excluded outright, a deliberately narrow v1 scope. Verified against a real import SwiftUI compile (not only a fake minimal stand-in) across four representative shapes — plain .task(id:), .task(id:priority:), a multiline id: expression, and a nested modifier chain — all compile clean both before and after mutation; removing id: and optionally priority: resolves to SwiftUI's own already-shipped zero/one-argument task(...) overloads, never an unmatched shape. Corpus-measured 2026-09 on zubair-io/Maple's MapleUI package (4/4 real production candidates discovered and compile-viable, 0 unviable): a coverage-instrumented rerun found 3/4 unambiguously noCoverage and the fourth attribution-ambiguous (flagged as an unresolved MutantKit coverage-attribution limitation, not a real kill opportunity) — 0 of the 4 candidates executed even once, confirmed independently by direct source inspection (no test in this package constructs any of the four affected Views; two of the four have their underlying async method tested directly, but that bypasses the View's body/.task modifier entirely). A standalone, disclosed fixture (not run through this operator — it contains no real .task(id:) syntax) demonstrates the abstracted restart-vs-no-restart fault shape is killable in principle by a test that can observe it. Promotion decision: remain experimental — a stronger, more definitive absence of real-world signal than post-await-cancellation-guard-removal's own 0/5-killed-but-covered result: this operator's real corpus never even reached the point where changed SwiftUI identity semantics could be exercised, a structural consequence of SwiftUI's own testability-under-plain-XCTest gap rather than a matcher or compile-safety defect. Full evidence, the second-corpus search (including six real projects independently found writing "source contract tests" against this exact fault by a different mechanism), and the adversarial review: Research/corpus-validation/task-id-removal-2026-09/.
apple.lifecycle.foreground-event-replacement	experimental	experimental	Replaces UIApplication.didBecomeActiveNotification with UIApplication.willEnterForegroundNotification, or the reverse, matched only on the exact UIApplication.<member> member-access form. Models two distinct, direction-specific faults: Variant A (didBecomeActive -> willEnterForeground) — grounded in Bugsnag Cocoa's own launch/session regression, where a non-UIScene app's launch path emitted didBecomeActiveNotification but not willEnterForegroundNotification, so activation-time work moved onto the latter would silently be skipped on that path; Variant B (willEnterForeground -> didBecomeActive) — foreground-entry-only logic incorrectly running on every activation, including a transient system-interruption re-activation that is not a true background-to-foreground transition. Deliberately excludes the dot-shorthand implicit-member form (.didBecomeActiveNotification), the legacy Objective-C-bridged spellings, NSApplication's equivalents, every other UIApplication lifecycle notification, and Scene-phase events — a disclosed v1 scope, not a broader claim. Verified against a real swiftc compile using the actual UIKit module on the current Apple SDK (both constants are same-typed, non-generic static let Notification.Name properties — a same-namespace value swap, structurally simpler than every other operator in this catalog family, with no generic-inference or empty-block hazard to guard against). Corpus-measured 2026-09 on segmentio/analytics-swift's iOSLifecycleMonitor.swift (SHA c9a0d6305ac44dcacffeb450534ee8af214b6607): full 4/4 candidates, 3 killedByAssertion (Variant A: 1/2; Variant B: 2/2), 1 survived (Variant A, individually root-caused as a genuine equivalent mutant — an already-present sibling switch case for the replacement value made the mutated arm unreachable dead code, confirmed by Swift's own first-match switch semantics, not a matcher defect), 0 unviable, 0 infrastructureFailure, 0 integrity violations. The killing tests exercise a real wasBackgrounded-gated state machine through an explicit background-then-foreground sequence, not a bare notification-fired check — the strongest single-project real signal in this operator batch. Two further real candidates (mixpanel/mixpanel-swift, ReactiveX/RxSwift) were found and investigated but rejected as unreachable without editing the external project's own scheme/test-target configuration, which the task contract forbids. Promotion decision: remain experimental, not promoted to confidence: .medium — both directions have real signal and neither is contradicted by the evidence, but this catalog's own precedent for a .medium promotion required two independently-verified real projects, and only one was found reachable this round despite a genuine search. Full evidence, the two rejected candidates' own reasoning, and the adversarial review: Research/corpus-validation/foreground-event-replacement-2026-09/.
apple.accessibility.explicit-label-removal	experimental	experimental	Removes an explicit SwiftUI .accessibilityLabel(...) modifier call by replacing the whole call with its own receiver expression (view.accessibilityLabel(label) -> view), never by deleting a containing statement — required so a closure-return shape like apply { view in view.accessibilityLabel(label) } stays a valid View-returning closure after mutation. Matches only a FunctionCallExprSyntax whose callee is .accessibilityLabel by exact name with a non-nil receiver; no argument-shape inspection at all, so it is unaffected by which SwiftUI overload is in play. Grounded in RevenueCat/purchases-ios PR #7357 (a real, community-reported VoiceOver failure on an icon-only paywall button, fixed by exactly the closure-return shape above, with the project's own commit message documenting a hand-verified RED/GREEN cycle) and Element X iOS PR #5890 (three more real explicit-label additions: a pinned-message banner, its "view all" button, and an avatar-edit button). Verified against a real import SwiftUI compile across 5 representative shapes (simple chain, inside a some View body, the closure-return form, a chain with modifiers before and after, and the Text(...) argument form) — 0/5 unviable. This is the first operator whose fault model requires the UI-test execution substrate as its validation surface (Research/phase5a-ui-test-substrate-2026-09/): proved end to end against Fixtures/AccessibilityUISubstrate with a real operator-generated mutant (not hand-applied), killedByAssertion by the real XCUITest, zero integrity violations — pipeline proof, not counted as external corpus evidence. External corpus 2026-09: element-hq/element-x-ios (SHA 99ba9eb23550997e569d362acbf2815411531d7b) got a full real campaign — 1/3 known PR candidates killedByAssertion (a true regression: .accessibilityElement(children: .ignore) blocks any fallback name), 2/3 survived and individually classified as non-matcher-defects (one equivalent/redundant — the fallback Text child carries the identical string; one a real test-oracle gap — a placeholder-initial fallback is non-empty but wrong, so a presence-only audit accepts it) — 0/90 false positives across the full discovered set. RevenueCat/purchases-ios (SHA 0a8b6e0959730d28e6d3a0811f02a4592ee7d9af, the operator's own primary fault-evidence source) got full discovery-only evidence instead of a real campaign: a genuine, reproducible tuist generate hang on the validation machine (root-caused across five variants, not a first-try abandonment — the project's UI-test target is Tuist-only) blocked every execution step, but pure-syntax discovery across the real, unmodified, full RevenueCatUI source tree found exactly the PR's own fix site plus 7 more real candidates, 0/8 false positives. Promotion decision: remain experimental — one project has a real executed kill plus honestly-classified non-defect survivors, and a second has the exact real fault site confirmed by discovery with zero false positives, but the two-independent-real-project bar for .medium requires two executed campaigns, which a genuine infrastructure blocker (not an absence of a second real project) prevented this round. Full evidence, the Tuist-hang root-cause diagnosis, survivor classification, and the adversarial review: Research/corpus-validation/explicit-label-removal-2026-09/.
apple.swiftui.hit-area-shape-removal	experimental	experimental	Removes an explicit .contentShape(Rectangle()) modifier call attached to (or nested inside) a SwiftUI Button's label content, replacing the whole call with its own receiver expression, so a control that visually occupies a larger rectangular area loses its explicitly expanded tap area, leaving only its rendered glyph/content pixels hit-testable. Matches only the exact single-argument Rectangle() shape (rejects Circle()/Capsule()/RoundedRectangle(...), the eoFill:-taking overload, and the ContentShapeKinds-taking overload — none has Rectangle() as its sole unlabeled argument) under a required Button-ancestry check: nested inside a Button's label closure (two-trailing-closure form, labeled-argument form, or a single-trailing-closure Button(action:) form recognized by the presence of a real action: argument), or chained directly onto the Button call's own result. The latter two closure/chain shapes were added mid-round after a real corpus audit against cwharris77/depth found them as real, in-scope attachment points an initial label-closure-only matcher missed. Grounded in cashubtc/wallet PR #305 (a real iOS mint-selector bug: a "liquid glass" pill drawn across a padded frame did not expand its own hit area) and cwharris77/depth PR #476 (five independent picker-sheet/list rows sharing the identical HStack { Text; Spacer; trailingGlyph }-inside-Button-with-no-contentShape shape) — both PRs independently confirmed to exist and be merged on GitHub via their real diffs. Verified against a real import SwiftUI compile across 5 representative shapes (Button label HStack+Spacer, .plain button style, modifier before/after padding/frame, a nested VStack view-builder context, a helper function returning some View) — 0/5 unviable. Proved end to end against the AccessibilityUISubstrate fixture with a real operator-generated mutant (not hand-applied): the existing wide itemRow button's .contentShape(Rectangle()) is discovered and removed, and a real XCUITest coordinate tap in the row's transparent dead center fails to register, killedByAssertion — pipeline proof, not counted as external corpus evidence. External evidence 2026-09: the operator's own discovery was run against both PRs' real, current source trees and confirmed to find every known fix site (depth: all 5 PR #476 sites among 16/20 real .contentShape(Rectangle()) occurrences discovered project-wide — the 4 excluded occurrences are genuine gesture-only, drag-reorder, Link, and Menu uses, all correctly out of this operator's declared Button-only v1 scope; cashubtc/wallet: all 3 PR #305 sites among 45 candidates discovered project-wide) — but neither project produced an executed campaign: depth's own Debug.xcconfig points its Supabase client at http://127.0.0.1:54321, a local dev stack this environment cannot start (no docker/supabase CLI on the validation machine — a genuine, root-caused infrastructure block, confirmed by a real baseline UI-test run failing at app launch before any mutation was ever applied, not a matcher or harness defect), and cashubtc/wallet's existing UI test suite (onboarding, settings, receive/send empty-states) never taps the mint-selector's own hit-testable region, confirmed by reading every UI test file. Promotion decision: remain experimental, not promoted to confidence: .medium — real fault evidence, clean compile safety, and confirmed discovery of every known fix site on two real projects, but zero executed real-project campaigns is well short of this catalog's own two-independently-executed-campaign bar for .medium; per this batch's own governing rule, an infrastructure block on one project never lowers that bar. Full evidence, the corpus audit that broadened the matcher mid-round, survivor/false-positive classification, and the adversarial review: Research/corpus-validation/hit-area-shape-removal-2026-09/.

LifecycleSuperCallRemovalOperator remains an unregistered demonstration of the extension point (no RED tests, not reachable from the CLI) pending its own fault study — a different, not-yet-started slice of the same taxonomy work. Its doc comment also notes a real, unfixed guard bug found while developing continuation-resume-removal's own switch-case exclusion: deleting the sole super.foo() call from an if/switch/catch branch would hit the identical empty-case compile error continuation-resume-removal guards against — tracked as a known issue against this operator, not fixed here since it is not currently reachable from the CLI either way.