Wave 11: ActionSheetPeerItem de-Postboxed. Revisits wave-1 abandonment.
`postbox: Postbox, network: Network` init params collapse to
`stateManager: AccountStateManager`; avatar setPeer call routes via
`item.stateManager.postbox` / `.network`. Module never names Postbox.
Sole caller (ShareController.swift:1146) migrated in place.
Wave 12: HorizontalPeerItem de-Postboxed (same pattern). Ripples the
collapse up into ChatListSearchRecentPeersNode's public init
(`postbox:/network:` -> `stateManager:`). That module still imports
Postbox for PostboxViewKey/UnreadMessageCountsView internals but its
public surface simplifies. 3 external caller sites migrated.
Wave 13: AttachmentTextInputPanelNode minor cleanup. Module was already
Postbox-free at source level (wave 6) but carried a dead BUILD dep and
had 2 raw `peerId?.namespace == Namespaces.Peer.SecretChat` checks.
Both now use existing `PeerId.isSecretChat` extension in TelegramCore.
Wave 14: BUILD-dep sweep mirroring wave 6's source sweep. 98 modules
had `//submodules/Postbox:Postbox` (or `//submodules/Postbox`) BUILD
deps despite no source file importing Postbox since wave 6. Single
iteration, zero restores -- Bazel Swift requires source-level `import`
for symbol resolution, so redundant BUILD deps are pure metadata.
Net: 110 files, +116/-149. Build verified green (debug_sim_arm64).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Closes the last future-wave candidate from wave 8 by eliminating the
Icon.media(Media, ...) enum case in StorageFileListPanelComponent.swift
and dropping import Postbox. StorageUsageScreen (the module as a whole)
is now fully Postbox-free.
Icon enum split:
case media(Media, TelegramMediaImageRepresentation) ->
case mediaFile(TelegramMediaFile, TelegramMediaImageRepresentation)
case mediaImage(TelegramMediaImage, TelegramMediaImageRepresentation)
Equatable rewritten as switch-over-tuple with id-based equality per
concrete type (lFile.fileId == rFile.fileId / lImage.imageId ==
rImage.imageId), same semantics as the old media.id comparison.
Binding site: `if case let .media(media, representation)` +
`as? TelegramMediaFile` / `as? TelegramMediaImage` downcasts ->
compound case-binding `case let .mediaFile(_, representation), let
.mediaImage(_, representation):` to lift the shared representation
variable, plus an inner switch for the setSignal branch. The compiler-
enforced exhaustiveness of the split improves call-site safety.
Construction sites (2): `.media(file, representation)` -> `.mediaFile(
file, representation)`, `.media(image, representation)` -> `.mediaImage(
image, representation)`.
Placeholder fixup:
messageId: EngineMessage.Id(peerId: PeerId(namespace: PeerId.Namespace
._internalFromInt32Value(0), id: PeerId.Id._internalFromInt64Value(0)
), namespace: 0, id: 0)
->
messageId: EngineMessage.Id(peerId: component.context.account.peerId,
namespace: 0, id: 0)
Inside a measureItem layout-measurement instance. Caught by second-pass
build failure `cannot find 'PeerId' in scope`. PeerId / PeerId.Namespace
/ PeerId.Id are raw Postbox types (not TelegramCore typealiases —
consistent with wave 9's MessageId -> EngineMessage.Id fixup). Using
context.account.peerId is semantically equivalent for the measurement
use case (messageId only feeds image-fetch userLocation and Equatable
comparison, neither exercised for this standalone instance).
Net: 1 file changed, +22 / -29 lines.
Plan: docs/superpowers/plans/2026-04-20-postbox-to-telegramengine-wave-10.md
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Closes the first of the two future-wave candidates left open by wave 8 by
rewriting both AccountSpecificCacheStorageSettings preferences-view
observation sites in StorageUsageScreen.swift using engine APIs, and
drops import Postbox from that file.
Site 1 — cacheSettingsExceptionCount (former 1047-1087):
postbox.combinedView(keys: [.preferences(keys: Set([...]))]) +
PreferencesView ->
context.engine.data.subscribe(TelegramEngine.EngineData.Item
.Configuration.ApplicationSpecific-
Preference(key: ...))
+ preferencesEntry?.get(...)
Site 2 — peerExceptions (former 3131-3196):
- Same preferences-observation replacement as Site 1.
- postbox.transaction { transaction.getPeer / getPeerCachedData as?
CachedGroupData / CachedChannelData; FoundPeer(peer:subscribers:) }
-> context.engine.data.get(EngineDataMap(...TelegramEngine.Engine-
Data.Item.Peer.Peer.init(id:))) + pattern match on EnginePeer
.user / .secretChat / .legacyGroup / .channel
- Signal element: [(peer: FoundPeer, value: Int32)] -> [(peer: Engine-
Peer, value: Int32)]. FoundPeer wrapper and its `subscribers` field
dropped — computed but never read downstream (consumers only read
.isEmpty, .count, and .prefix(3).map { EnginePeer($0.peer.peer) }).
Consumer update:
peerExceptions.prefix(3).map { EnginePeer($0.peer.peer) } ->
.prefix(3).map { $0.peer }
Typealias fixup (caught by first-pass build failure):
var mergedMedia: [MessageId: Int64] -> [EngineMessage.Id: Int64]
(MessageId is raw Postbox; must use the EngineMessage.Id typealias
when import Postbox is removed.)
Reusable pattern documented in CLAUDE.md: TelegramEngine.EngineData.Item
.Configuration.ApplicationSpecificPreference(key: ValueBoxKey) is the
general-purpose engine replacement for the postbox.combinedView(keys:
[.preferences(keys: Set([key]))]) + PreferencesView idiom. Works from
any module importing TelegramCore (without import Postbox) because
passing PreferencesKeys.<name> keeps ValueBoxKey as an inferred-only
type that never gets named in the consumer.
Net: 1 file changed, +30 / -54.
StorageUsageScreen.swift is now Postbox-free. The wave 8 outcome's other
future candidate (StorageFileListPanelComponent.swift's Icon.media(Media,
...) enum case) remains — trivial future wave will land the whole-module
drop.
Plan: docs/superpowers/plans/2026-04-20-postbox-to-telegramengine-wave-9.md
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Narrow consumer-module migration of raw Message types to EngineMessage in
the StorageUsageScreen component. Two files touched; the module keeps
import Postbox because of two out-of-scope site clusters (preferences-
view observation + a Media-carrying Icon enum case) — both flagged in
CLAUDE.md and the wave doc as future-wave targets.
StorageUsageScreen.swift:
SelectionState.togglePeer(availableMessages:)
[EngineMessage.Id: Message] -> [EngineMessage.Id: EngineMessage]
AggregatedData.messages
[MessageId: Message] -> [EngineMessage.Id: EngineMessage]
AggregatedData.clearIncludeMessages / .clearExcludeMessages
[Message] -> [EngineMessage]
AggregatedData.init messages param — same swap
RenderResult.messages
[MessageId: Message] -> [EngineMessage.Id: EngineMessage]
openMessage(message: Message) -> openMessage(message: EngineMessage)
(unwrap to raw at OpenChatMessageParams
/ chatMediaListPreviewControllerData
call sites via ._asMessage())
StorageFileListPanelComponent.swift:
Item.message: Message -> EngineMessage
(internal .id / .timestamp / .media
usage compiles unchanged against the
EngineMessage class).
Wave-7 facade-boundary bridging dropped:
- renderStorageUsageStatsMessages call site: the .mapValues(EngineMessage.init)
on existingMessages and .mapValues { $0._asMessage() } on the result vanish;
AggregatedData.messages and RenderResult.messages are now engine-typed on
both sides of the facade.
- clearStorage call sites (2): the .map(EngineMessage.init) wraps around
includeMessages / excludeMessages vanish; locals become [EngineMessage].
- Inside AggregatedData.updateSelected... accumulation loop, four
item.message._asMessage() calls (where item.message was EngineMessage
and the target was [Message]) drop back to plain item.message.
- StorageMediaGridPanelComponent.Item(message: EngineMessage(message), ...)
at the RenderResult-build loop loses the EngineMessage(...) wrap since
`message` is already EngineMessage.
Out of scope (module keeps import Postbox):
- StorageUsageScreen.swift:1047-1062 / 3131-3185 — AccountSpecificCache-
StorageSettings observation via postbox.combinedView + PreferencesView
and a postbox.transaction block doing transaction.getPeer / getPeerCached-
Data as? CachedGroupData/CachedChannelData for peer-category classification.
- StorageFileListPanelComponent.swift:105 — Icon.media(Media, ...) enum case.
Constructed only as .media(TelegramMediaFile, ...) or .media(TelegramMedia-
Image, ...); trivial future wave to split into two cases.
Build verified green: 59s incremental, 27 actions, Telegram.ipa produced.
Plan: docs/superpowers/plans/2026-04-20-postbox-to-telegramengine-wave-8.md.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Closes the seven remaining raw-Postbox leaks in TelegramEngine public
facades surfaced by a post-wave-6 scouting pass (all non-permanently-
blocked candidates).
Facades migrated in place (6 rewrites + 1 deletion; all _internal_*
implementations unchanged per the "internal Postbox-facing stays raw"
rule):
Messages:
downloadMessage Signal<Message?> -> Signal<EngineMessage?>
topPeerActiveLiveLocationMessages Signal<(Peer?, [Message])> -> Signal<(EnginePeer?, [EngineMessage])>
getSynchronizeAutosaveItemOperations deleted (dead facade; sole caller uses _internal_ directly)
Peers:
updatedRemotePeer Signal<Peer> -> Signal<EnginePeer>
(PeerReference param kept; no EnginePeer.Reference alias today)
Resources:
renderStorageUsageStatsMessages [EngineMessage.Id: Message] -> [EngineMessage.Id: EngineMessage]
clearStorage(peerId: ...) [Message] -> [EngineMessage]
clearStorage(peerIds: ...) [Message] -> [EngineMessage]
clearStorage(messages:) [Message] -> [EngineMessage]
(no external callers; migrated for overload-set consistency)
Consumer call-site updates (5 files):
- ChatListSearchListPaneNode drop redundant .flatMap(EngineMessage.init) wrap
- LocationViewControllerNode drop redundant .map(EngineMessage.init) wrap
- LiveLocationSummaryManager drop redundant EnginePeer(...) / EngineMessage(...) ctors
- StorageUsageScreen bridge [Message] <-> [EngineMessage] at the 4 facade-call points
(internal [MessageId: Message] / [Message] storage kept;
full-consumer-module migration is out of scope)
Discovery: grep of TelegramEngine/*/TelegramEngine*.swift public signatures
for `: Postbox|: Account|: MediaBox|: MediaResource|: Peer\b|: Message\b|
-> Signal<.*(Peer|Message)` turned up these seven candidates and no others.
After this wave, the full TelegramEngine.* facade surface is engine-typed
modulo the four permanently-blocked TelegramMediaResource-conforming
classes recorded in CLAUDE.md (ICloudFileResource, InstantPageExternal-
MediaResource, VideoLibraryMediaResource, YoutubeEmbedStoryboardMedia-
Resource).
No modules became Postbox-free in this wave. Plan: docs/superpowers/
plans/2026-04-20-postbox-to-telegramengine-wave-7.md.
Full project build verified green.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The wave-6 commits (spec, plan, C1 batch drop, C2 tally) were
squashed into a single commit, shifting the SHA referenced twice in
the wave-6 outcome section. Updates the two "see git show <sha>"
pointers to the new squashed commit.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
First build-verified unused-import sweep: speculatively dropped
import Postbox from 782 consumer files (plain ^import Postbox$ lines,
excluding TelegramCore/Postbox/TelegramApi paths), iterated 18 full
project builds with --continueOnError, restored the import on every
file that failed to compile. 183 drops survived; 189 consumer modules
newly Postbox-free.
Bundled: spec + plan + C1 atomic batch drop + C2 CLAUDE.md outcome and
permanent methodology guidance under Wave-selection. The methodology
subsection captures the reusable playbook (--continueOnError is
essential, dependency graphs are deep so expect many iterations,
pattern-based preemptive restores accelerate convergence, and
CLAUDE.md's engine typealias cheat sheet arrows are migration targets
rather than typealiases in TelegramCore).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Migrates uploadSecureIdFile's public signature from (context:,
postbox: Postbox, network: Network, resource: MediaResource) to
(context:, engine: TelegramEngine, resource: EngineMediaResource).
SecureIdVerificationDocumentsContext refactored to hold
engine: TelegramEngine instead of raw postbox + network, drops
import Postbox (tally +1). The one instantiation site in
SecureIdDocumentFormControllerNode updates to pass
engine: self.context.engine.
Completes the last explicitly-named future-wave candidate from
CLAUDE.md.
Bundled: spec + plan + C1 atomic migration + CLAUDE.md outcome.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Adds three thin forwarding methods on TelegramEngine.Resources
(fetch, status, data) over MediaBox, then migrates SaveToCameraRoll's
three public functions to use them, drops import Postbox from the
module (source + Bazel dep), and updates all 23 call sites across 14
caller files atomically.
Bundled: spec + fix + plan + C1 facades + C2 SaveToCameraRoll rewrite
+ BUILD dep drop + CLAUDE.md outcome.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Reflects the current state of the Postbox → TelegramEngine refactor:
- Header now lists waves 1 and 2 with their plans.
- New "Wave 2 outcome (2026-04-17)" section enumerates the five
migrated TelegramEngine facades, the one fully de-Postboxed
consumer submodule (MapResourceToAvatarSizes), the AuthorizationUI
signal type swap, and the abandoned Task 8 (SaveToCameraRoll).
- Wave-selection guidance extended with two lessons learned:
(a) planning-time inventories should grep the full Postbox token
set, not just the tokens specific to the wave's goal, to avoid
execution-time abandonments like wave 2's SaveToCameraRoll; and
(b) facade-API migrations (wave 2's shape) work better than
per-module Postbox drops (wave 1's shape) when the target is a
shared API surface.
- New "Modules currently free of import Postbox" tally lists the
8 consumer modules now clean across all waves and the standalone
PromptUI / PresentationDataUtils / StickerPeekUI cleanups.
- New "Known future-wave candidates" section records the three
leaks surfaced by the wave-2 final review and the four permanently
blocked TelegramMediaResource-conforming classes.
Docs-only change. No behavior change.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Drive raw `MediaResource` out of the `TelegramEngine` public facade for
photo-upload APIs, and complete a first batch of consumer-side
migrations. Behavior-preserving. The `_internal_*` Postbox-facing
functions are untouched — only the facade signatures change, bridging
inside via `_asResource()` / `EngineMediaResource(_:)`.
TelegramEngine facades migrated (signatures now take EngineMediaResource):
- TelegramEngine.Peers.uploadedPeerPhoto / uploadedPeerVideo
- TelegramEngine.Peers.updatePeerPhoto (closure param too)
- TelegramEngine.AccountData.updateAccountPhoto / updateFallbackPhoto
- TelegramEngine.Contacts.updateContactPhoto
- TelegramEngine.Auth.uploadedPeerVideo
Consumer-side changes:
- MapResourceToAvatarSizes utility: signature is now
(engine: TelegramEngine, resource: EngineMediaResource, ...). Uses
engine.resources.data(id:) internally. The submodule drops
`import Postbox` and the Bazel dep.
- AuthorizationUI: avatar-video signal retyped from
Signal<TelegramMediaResource?> to Signal<EngineMediaResource?>.
- 27 `mapResourceToAvatarSizes(postbox:...)` call sites across 5
TelegramUI/TelegramCallsUI files migrated to the new form.
Deferred:
- SaveToCameraRoll (planned Task 8) abandoned — module has three
public functions taking `postbox: Postbox` (umbrella-type leak,
banned by rule 2) and requires a full module-migration wave, not a
type swap. Reason recorded in the wave-2 plan doc.
- Other TelegramEngine facades still leaking MediaResource
(TelegramEngineStickers.uploadSticker; UploadSecureIdFile.* —
additionally leaks Postbox) flagged for a future wave.
Docs:
- CLAUDE.md: new rule 7 (TelegramCore never imports UIKit/Display,
shared with Telegram-Mac), and a new "MediaResource →
EngineMediaResource consumer migration" section describing the
wrap/unwrap helpers and the modify-in-place facade-bridging
pattern.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Drop direct `import Postbox` from four leaf consumer submodules, routing
data access through TelegramEngine/TelegramCore. Behavior-preserving.
Consumers migrated:
- ChatInterfaceState
- ChatSendMessageActionUI
- ContactListUI
- DrawingUI
TelegramCore additions (typealiases + one EngineData item):
- EngineMemoryBuffer, EnginePostboxDecoder, EnginePostboxEncoder,
EngineAdaptedPostboxDecoder (narrow utility aliases for coding support)
- EngineData.Item.Configuration.ContactsSettings
Six planned modules were abandoned in wave 1 with reasons recorded in
the plan: ActionSheetPeerItem, ChatListSearchRecentPeersNode,
DirectMediaImageCache, FetchManagerImpl, GalleryData, ICloudResources.
Each either has a public API that leaks `Postbox`/`Account`/`MediaBox`
(banned umbrella-type aliases) or cascades into out-of-wave modules.
CLAUDE.md now records the wave rules, typealias cheat sheet, and the
wave-selection guidance learned from this pass.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
