Repository navigation
feat(telegram): generated Telegram Android and Desktop port with one-command cloud publisher - #70
Merged
Merged
Conversation
Lands what both Telegram work packets build on: the telegram-theme port format, byte artifacts in the port pipeline (the same three hunks as #69, so the later merge is trivial), the pinned upstream key registry with its maintainer extractor, the shared artifact/MIME/slug contract, the public cloud.json distribution config, and teleproto pinned exactly for the owner-run publisher (vetted: no install scripts, signed tree). The emitter is a stub until the mapping packet lands; ports/telegram has no port.json yet, so validate fails on this intermediate commit by design. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…th installation Outgoing bubbles used surface.chrome-alt, the same value as the wallpaper gradient end, so they vanished near the composer. Bubbles now step up a lightness ladder of canonical surfaces (wallpaper canvas to chrome, incoming raised, outgoing overlay), which keeps red links and subtle timestamps above 4.5:1 on both bubbles; tests pin the ladder and the new metadata pairs. The README now leads with two-step Android and Desktop instructions generated from cloud.json (files until the cloud theme is verified, the shared link after), and the owner and maintainer notes are consolidated into PUBLISHING.md and IMPLEMENTATION.md. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…d near-white Review r1 (CHANGES_REQUIRED) found that the release hook recorded a successful Telegram deployment even when it refused an old rerun, so a later rerun could republish older files. The decision now runs in a gate job with no environment and passes only for the current tip of main with changed dist bytes; the publisher checks the tip again and, in CI, only updates the identity a verified local publication recorded in cloud.json (ci-enable refuses before that). It also adopts an owned theme at any candidate before creating one. Publisher corrections: results are labelled from verified state (an update whose response was lost is "updated"), only definite auth errors read as "not authorized" (teleproto's own check swallowed transient failures), local publishing is HEAD-only with older revisions through rollback, live client calls have timeouts, checks run without an npm shim and receipt names avoid ":" (Windows), confirmations are visible, and disconnect --ci disables publishing before deleting secrets and tolerates missing ones. Visual corrections: read and verified ticks and attach/file-download icons no longer sit near-white on dark backgrounds (accent ticks; buttons on the action fill); bot-keyboard labels and code comments get readable text roles instead of Telegram's translucent dark defaults; the sticker selector line is visible; the key extractor now records Theme.key_-qualified fallbacks. The near-white test classifies by luminance against a reviewed key list, and the install text no longer goes stale after publication. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… delta review findings Delta review 1 found the near-white list only froze the emitted set. The test now resolves every registry key's runtime value (inherited keys included) and requires each near-white glyph to name the backgrounds it is drawn on, each a selection, action or danger fill (or the media scrim) at 4.5:1. That exposed and fixed: selected emoji/glass/profile-tab glyphs and the account check (now accent), the Desktop sidebar and muted unread badges (each state on a dark-red fill; the active badge no longer matches the active row), archived and profile avatars, the blue switch track, the tray mute counter, the media overview check and the photo loader scrim. The publisher now applies the bounded flood wait to the startup and post-login authorization checks, and disconnect --ci reads what exists so a rerun after an interruption continues while real failures still stop it. The key extractor accepts upstream spacing and strips Java comments (201 fallbacks), and the coverage table in IMPLEMENTATION.md is generated. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…osite scrims in contrast checks Delta review 2 traced Telegram Desktop's badge painter: one count colour per row state serves the unread, reaction and poll badges, and the reaction and poll fills are the same keys as the draft label and the poll icon on the black row. A dark fill cannot also be readable label text, so near-white counts left the active reaction badge invisible (1:1) and several states below 4.5:1. Desktop badges are now light pills (accent, or muted rose when muted) with dark text.inverse counts; on the selected row the pill is near-white or rose with the count in the row colour. A test checks every family and row state from the pinned unread_badge_paint.cpp at 4.5:1. Contrast checks now composite translucent backgrounds over white and black (a raw scrim colour overstated contrast), selected thumbnail icons are checked on the image scrim they are drawn on, and the controller authorization tests cover the post-login wait and the CI caps. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…e tests, docs The unselected document-thumbnail download glyph was 1.91:1 over bright media: it now uses the on-action glyph role on its image scrim, like its selected sibling (round-video progress keeps its accent explicitly). The Desktop badge count uses text.on-light, the canonical role for text on light fills (same pixels as before). The badge test now also covers the pills against their rows at 3:1, the wide mention/reaction/poll icons, the active wide glyph and the muted glyph set; the near-white check and the compositing counterexample share one helper, so dropping the underlay fails the suite; badge contrast refuses a translucent background instead of measuring it uncomposited. The notes name the Desktop chat-list badge fills as a host-forced departure from the canonical Badge count variant. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…yphs at 4.5:1 Delta review 4 found the thumbnail download glyph also draws on Telegram Desktop's 40% song-cover/upload overlay, which the theme left at its host default (2.48:1 over bright media). The overlay now uses the existing media scrim projection. Tracing the same draw paths, the generic document squares in the Files overview (msgFile1-4Bg/Dark/Over) were dark surfaces behind the near-white icon, radial and extension label; they are now the action fill and its hover. The near-white table names every one of these backgrounds and the composited check covers them. The notes record that Desktop style-file colours outside the palette resolve through palette keys. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ce-metadata
Bot
added
area:design-system
…an API application The owner created the j3w1 cloud theme in Telegram's own Theme Editor (themes.contest.com), and my.telegram.org currently refuses to create the API application the publisher needs. The port therefore has to work end to end without one: the Theme Editor's Import file and save become the first-class owner route, and npm run telegram:publish stays as optional automation. - cloud.json (schema 2) records the editor-created theme's Telegram-generated slug TRhfHcbvZHlOucyc. `published` becomes `verified`: set by hand only after the owner applies the install link on Android and Telegram Desktop and records evidence. Neither an editor save nor a publisher readback sets it. - The invalid 4-character `j3w1` candidate is gone. Both pinned clients accept 5-64 characters of [A-Za-z0-9_] that start with a letter and do not end with "_", and the contract now enforces exactly that. - The publisher adopts the recorded theme by its slug and never creates a second one. A first publication of a new theme records only its slug. CI and ci-enable wait for `verified`. - The README, generated from cloud.json, leads with file install until the link is verified, and adds the Theme Editor steps. A generated card in PUBLISHING.md names the slug, the install link and its state, the Android and TDesktop editor tabs, and the files. The verified-state Desktop step now uses the client's own label, "Apply this theme", instead of "Apply". - PUBLISHING.md separates the Theme Editor route from the optional publisher. IMPLEMENTATION.md shows both routes converging on one identity, keeps the six acceptance facts apart, and lists the screens for the visual check. Tests cover all three cloud states, the editor and install link consistency, the slug rules, adoption of the editor theme without a second theme, and the absence of credential readers outside the publisher and CI. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…s stock colours The owner's Android import in Telegram's Theme Editor carried all 667 values the file sets, but the editor gave every key the file left out Telegram's stock colour. That broke the clients' inheritance on the cloud route: read ticks turned green, value icons and switches blue, and search text dark grey. It also wrote 77 keys the pinned client no longer reads, such as a blue chat_attachFileBackground and a green chat_outPreviewInstantSelectedText. - Inherited keys are now written with the value they inherit: Android's one direct fallback, and Desktop's alias or fallback chain. A file import renders exactly as before, and the editor has nothing left to fill. Unset keys stay out, and the editor knows none of them. - src/editor-keys.json lists the 77 legacy Android keys with their source. chat_attachFileBackground, chat_goDownButtonIcon and dialogCameraIcon were last read by Telegram Android 11.4.2; the rest were gone by 9.7.6. mapping.json gives each the role of its current counterpart, so older clients and the editor text stay on palette. - Android drew the file and voice button icon (chat_*MediaIcon) on the loader circle (chat_*Loader) in the same rose, so the icon was invisible. These buttons now use a dark-red circle with a near-white icon, matching Desktop's file circles. The media mini badge ring follows. Simulated against the editor's 2026-10-05 output, all 119 editor-filled keys now come from j3w1, and the Android file uses only canonical j3w1 colours. Tests cover the explicit inherited values, the legacy keys, and the file and voice button contrast on both clients. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The owner's Android import confirmed the editor's labels: IMPORT FILE, then SAVE AND APPLY THEME, with no confirmation message after saving. The guide, PUBLISHING.md and IMPLEMENTATION.md now name those buttons instead of a generic "save the theme". Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ckground The owner's Android check showed the Settings "Help" header almost invisible. Telegram draws every list and settings section title (HeaderCell) in windowBackgroundWhiteBlueHeader; despite its name it is a text colour, and the mapping had given it surface.default. It now uses text.accent-strong, as Desktop's section titles (windowActiveTextFg) do. profile_tabSelectedText, which falls back to it, now inherits instead of repeating the same role. An audit of every Android key Telegram draws as a visible foreground in its own defaults found no other text key with a background colour. The coloured squares behind Android's Settings icons are fixed gradients in Telegram 12.x (IconBackgroundColors), not theme keys; IMPLEMENTATION.md now says so. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The owner's Android photos showed two near-white glyphs the theme cannot reach. The composer send and mic icons are always white on the accent-red chat_messagePanelSend circle (ChatActivityEnterView, new design). The profile action labels are white or black by brightness (ProfileActionsView). Both are now listed with the other host-controlled colours. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…dd button The owner's Windows check showed the channel UNMUTE bar in accent red on a dark-red fill (2.9:1, 2.5:1 on hover). tdesktop's historyComposeButton draws windowActiveTextFg on historyComposeButtonBg, which upstream aliases to the compose area. The explicit dark-red mapping is dropped, so the button inherits the compose area and windowBgOver again (about 6:1). An audit pairing every text colour with its background across the 73 pinned tdesktop and lib_ui style files found one more fixable pair: the voice-chat add-member label (groupCallMemberNotJoinedStatus, 3.3:1) now uses text.muted. The trending stickers' installed label reuses the primary fill as text, which no palette can satisfy; IMPLEMENTATION.md records it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ubbles and Desktop menu The owner's live check on Android and Windows found their own messages too hard to tell from other people's: outgoing surface.overlay (#241010) next to incoming surface.raised (#160b0b) is ΔE 7.4. Keeping timestamps and links at 4.5:1 caps how bright an outgoing bubble can be, and no approved surface below that cap carries visible red for this meaning. The owner chose a new role on an existing colour. - color.surface.accent (D-034, accepted 2026-10-06) reuses primitive ink.60 (#2b0e0d), so the palette gains no colour. text.default 7.82, text.muted 5.25, text.subtle 4.61 and text.link 4.88 on it; spec/contrast.json records the four pairs. - Telegram outgoing bubbles (chat_outBubble, msgOutBg) use it: ΔE 12.6 from incoming, which keeps its 4.2 from the wallpaper. A test holds ΔE >= 12. - Every other port classifies the role. Claude Code's userMessageBackground keeps its role for now (not-implemented); the rest have no such surface. Port token digests follow the new token set; their outputs are unchanged. The owner also saw a two-tone Desktop main menu: rows on windowBg (black) over a separate mainMenuBg (#241010). lib_ui aliases mainMenuBg to windowBg, so it now inherits it again, with a test. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…are dark surfaces The owner saw rose areas in Telegram Desktop. lib_ui describes emojiPanCategories as the emoji panel's category-strip background (#f7f7f7, falling back to windowBg), but the mapping gave it text.muted, so the strip was a rose bar. mediaviewTransparentFg, the second tone of the media viewer's transparency checkerboard, likewise showed rose against black. They now use surface.default and surface.chrome-alt. An audit of every key lib_ui calls a background found no others; the light unread pills are deliberate. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…by side The owner still saw too little difference between their own and other people's bubbles at #2b0e0d (ΔE 12.6). They compared four options rendered in real colours, with real text, timestamps and links, and chose the deepest red that keeps red links readable. - New primitive color.primitive.red.40 (#3d0c0a); color.surface.accent now points to it. Text on it: text.default 7.30, text.bright 8.74, text.muted 4.90, text.link 4.55. text.subtle falls to 4.30, so secondary text on the accent surface uses text.muted; spec/contrast.json pairs bright instead of subtle, and foundations.md states the rule. - Telegram bubble timestamps, clocks and durations (in and out, both clients) move from text.subtle to text.muted. Outgoing and incoming bubbles are now ΔE 24.0 apart (previously 12.6, originally 7.4), and the test requires at least 20. - D-034 records the second round and the rejected alternatives. Every port classifies the new primitive like its sibling red.50. Token digests follow; port outputs other than Telegram are unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…; README leads with the cloud link The owner completed live acceptance on 2026-10-06: - Theme Editor imports of the generated files into theme TRhfHcbvZHlOucyc. - The install link applied in Telegram for Android 12.10.6 and in Telegram Desktop 7.2.9 on Windows; the theme persisted across restarts. - Later cloud saves reached both clients without reapplying the link. - A visual check of the main screens, ending with "everything looks good now". The repository's verification policy requires a real import bound to the exact subject: - evidence/2026-10-06-import.json is a real-import record for subject sha256-aBor4iTY…, and the catalogue now computes "verified". - evidence/2026-10-06-acceptance.md is the readable account, with its limits: file import and Linux/macOS were not exercised, and the colours Telegram fixes in code are listed. - port.json declares status verified, both tested versions, and evidence entries with the current artifact digests. - cloud.json marks the link verified, so the generated README leads with "Open Install j3w1, tap Apply" on both clients. The tests now hold the claim to the current bytes. While the port says verified, the catalogue must agree and each evidence digest must equal its artifact. Any later change (such as the planned #69 rebase) fails until it is re-accepted or the status returns to experimental. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ing, summaries) Independent Codex review r7 of 89856d4..2da0f6a approved with three advisories. - r7-1: the bubble durations D-034 moved to text.muted had no contrast guard; remapping one to text.subtle passed at 4.30:1. The 4.5:1 pair test now covers audio durations on their bubbles and link-preview durations on both bubbles (ChatMessageCell chat_audioTimePaint, Theme chat_durationPaint). A role check also forbids text.subtle for every outgoing key and every key D-034 moved. The reviewer's counterexample now fails. - r7-2: #3d0c0a was described as the brightest red that keeps links at 4.5:1, but #3e0c0a and #3f0c0a also pass. D-034, the primitive's description and the changelog now call it the owner's choice from the side-by-side comparison, with links at 4.55:1, and state the real limit (#3f0c0a passes at 4.51:1, #400c0a fails at 4.48:1). - r7-3: the changelog called the port experimental with no new colours, and the role table put timestamps under text.subtle. Both now match the verified state and the mapping. The description change alters the token export's digest, so port token digests follow and the import record is re-bound to the new subject. Both artifacts are byte-identical and no resolved colour value changed; the record says so. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…8-1) Delta review r8 approved the r7 corrections and the re-bound record, but found the new outgoing-key guard too narrow. Its prefixes (msgOut*, history*Out*, mediaOut*) missed Desktop msgFileThumbLinkOutFg, the document link drawn on the outgoing bubble, so a remap to text.subtle (4.30:1 on the accent) still passed. They also missed the Desktop file fills and waveforms, and Android chat_messageTextOut, chat_messageLinkOut and the instant-view buttons. - Outgoing keys are now the chat_out* prefix or "Out" as a camel-case word, excluding Outer and Desktop's slideFadeOut* animation keys. That gives 37 Desktop and 95+ Android keys; none resolves to text.subtle today. - The document links get native 4.5:1 pairs on both bubbles, and the selected links on the selected bubbles (history_view_document.cpp, msgFileThumbLink*Fg). Remapping msgFileThumbLinkOutFg, chat_messageLinkOut, msgWaveformOutActive or chat_outAudioDurationText to text.subtle now fails the test; the mapping was restored byte for byte after each. Test-only: no artifact, token or evidence changes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The owner found selected text barely visible in the Android composer (2026-10-06). chat_textSelectBackground, which chat_in/outTextSelectionHighlight inherit, was mapped to interaction.marquee, the 12% drag-select tint. Over the black composer it showed as #120202, ΔE 5.2 from the field. It now takes interaction.selection.bg (#531310). Spec foundations make selection a fill in that role, and Desktop already uses it for selected text and its input fields (lib_ui input_field.cpp:2162). The selection now stands apart from the composer by ΔE 39 and from incoming bubbles by ΔE 34; rose text reads at 6.24:1 on it. The fill is opaque, so it gets its own reviewed exception (coverage.opaqueUnderText) to the rule that translucent-default keys stay translucent. Every pinned path draws it before the text: Android's editor (EditTextCaption:412, ChatActivityEnterView:5819), messages (ChatMessageCell:17065), link previews, fact checks, instant view (ArticleViewer) and stories. The generator accepts only the selection fill there, and tests require each entry to cite its draw path. A new test covers the reported defect. Remapping back to the marquee fails it, and any other opaque colour is refused. Known limits, documented in IMPLEMENTATION.md: - Android keeps text colours inside a selection, so a selected link is 3.89:1 while selected. - On the outgoing accent bubble the fill stands out by only about ΔE 10. The Android file changed (the Desktop file is byte-identical), so the 2026-10-06 acceptance no longer matches. The port returns to experimental and the cloud link to "awaiting verification" until the owner re-checks. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…tion uses it Independent review r10 rejected 24324ac's opaque Android selection fill. Pinned Telegram paths paint the selection fill after their content: the rich editor's tables, captions and media/map/audio/document blocks (RichTableCell.dispatchDraw, RichMediaCell.onDraw, RichCaptionController) and the rich-message translation preview. An opaque #531310 hides selected text and media there. The composer reads the same key, so the keys cannot be split. The opaque fill was also only ΔE 10.2 on the outgoing bubble. The owner compared the opaque fill with the text-selection red at 40, 50 and 60%, rendered in the message field, both bubbles and a rich-editor photo, and chose 50% (D-035, accepted). - New primitive color.primitive.alpha.red-50 (#911410 at 50%) and role color.interaction.text-selection.tint. - Composited, it stands ΔE 36.5 from the message field, 35.1 from incoming bubbles and 21.5 from outgoing bubbles. Rose text stays at 5.53:1 or above. - Links (3.45 to 4.30) and code keyword/string/comment colours (3.13 to 4.30) are below 4.5:1 while a selection lasts, which D-035 and IMPLEMENTATION.md record. - Two global contrast pairs; foundations' state table; every port classifies the role and primitive (Obsidian keeps text-selection.bg because it recolours selected text). - Telegram: chat_textSelectBackground takes the tint; the in/out highlights inherit it. - The opaqueUnderText exception, its generator carve-out and its tests are removed. The original translucency guard is restored unchanged (the generator equals 0b47ff3), and a test proves it refuses an opaque fill on the selection key. - The visibility test composites in 8 bits as Android does and holds all three surfaces, including the outgoing bubble, to the ΔE 20 floor. - r10-3: Telegram's text-selection.bg/.text reasons now say why they are not used. - The resolved token count is 350. Counterexamples: remapping to the marquee fails the visibility test; remapping to selection.bg is refused by the generator. The Desktop file is byte-identical to the accepted one. The port stays experimental until the owner re-checks Android. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Review r11 closed r10-1 to r10-4 with the guard identical to 0b47ff3, and asked for documentation corrections only. No colour, artifact or test threshold changes; the Telegram files are byte-identical. - r11-1: text stays at 4.5:1 only where the tint is drawn under it. Where Telegram paints it over the text (rich-editor tables and captions, the rich-message translation preview), selected text measures 2.96 to 3.43:1; no strength fixes both. D-035, the role description, CHANGELOG, IMPLEMENTATION and spec/accessibility.md now say so, and the owner's re-check list includes it. The owner's comparison did not show that case; D-035 records that. - r11-2: Obsidian keeps the text colour inside a selection (rose 3.96:1), so the tint fits it. Its classification and D-035 said the opposite. Adopting it in Obsidian is a separate change with its own import check. - r11-3: the code limits now name number and constant colours (3.13 to 4.40) and the ΔE 18.3 selection inside an outgoing code block. - r11-4: one meaning everywhere. The tint is for hosts that keep the text colour inside a selection; it is translucent, so it also suits hosts that paint the fill over their content. - r11-5: D-035 says its per-surface figures are Android 8-bit composites and that the canonical pairs cover the canvas only (6.91, 8.28). Links are not declared, because waivers are for decorative graphics only. - r11-6: test comment wording; the negative test pins the refused key; the text-selection.text reason names interaction.selection.text. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ory) Review r12 approved the r11 corrections and closed r11-1 to r11-6. Its one advisory: the code limit put number and constant colours in "3.13 to 4.40" everywhere, but they fall below 4.5:1 only in outgoing code blocks (4.40; 5.24 in incoming blocks). Keyword, string and comment are 3.13 to 4.24. D-035, IMPLEMENTATION.md and spec/accessibility.md now say so. Wording only; the Telegram files and tokens are unchanged. The component digest and chunk renames follow from spec/accessibility.md. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… re-check After D-035, the owner re-imported the Android file (c140143, unchanged since) through the Theme Editor and checked text selection on Telegram for Android 12.10.6: - the message field: "looks much better"; - their own message: the tint on the normal outgoing bubble, ΔE 21.5; - then the whole client: "everything looks good now". The Desktop file is byte-identical to the one accepted on Windows Desktop 7.2.9, and D-035 changes no Desktop key. - evidence/2026-10-06-acceptance.md: - the Android artifact is now sha256-Mwz/… (first accepted as SoKD…); - a "Re-check after D-035" section records what was and was not seen (no rich-editor or code-block selection; no line-by-line editor comparison this time); - the limits list the Desktop carry-over and the D-035 limits. - evidence/2026-10-06-import.json is bound to the current subject (sha256-bv0rd5…), with an "Android text selection (D-035)" check and the carry-over in its limits. - port.json is verified, with the Android evidence entry at the current bytes; cloud.json is verified. The README leads with the cloud link again, and CHANGELOG and IMPLEMENTATION say verified. The catalogue computes "verified" for the current subject. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…iew r13 Review r13 (re-verification and merge readiness) found PR #69 already records D-034 (Windows adapters, accepted 2026-09-28), a week before this PR's D-034. #69 is another session's work and is not touched, so this PR renumbers: the accent surface D-034 -> D-035, the text-selection tint D-035 -> D-036. A merged log then runs D-033, D-034 (#69), D-035, D-036. That covers 52 references in tokens, spec, CHANGELOG, Telegram's mapping, capabilities, IMPLEMENTATION, tests and evidence. Both decisions note the renumbering. Also from r13: - r13-2: the acceptance record says selection in someone else's message was asked for but not separately confirmed. - r13-5: the port's rule reads "re-checked on each client whose file it changes", as applied. - r13-7: the install text no longer says "when published". - r13-8: the record says the bubble ΔE and contrast are computed, quotes the final verdict with what it answered, and keeps the earlier re-binding chain in its limits. The token descriptions and port.json wording move the subject. Both Telegram files and every other port's dist are byte-identical, and no resolved colour value changes (metadata of four tokens only). So the import record is re-bound, description-only, from bv0rd5… to a+4Hk2…, as in r7-2/r8, and its limits disclose it. The catalogue computes "verified". Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Preserve main's optimized generators and Windows runtime bytes while merging the accepted Telegram accent and selection contracts. Regenerate all exports from the combined sources, retain every original contrast case, and keep the changed Telegram artifacts experimental pending renewed client imports.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds generated themes for the official Telegram for Android and Telegram Desktop, plus an optional owner-operated cloud publisher. Both native files come from canonical roles in one mapping. The publisher remains unconfigured and its CI hook remains disabled.
PR #69 merged first as
5518ecd980926ddb7fc1c797d5785ae6955197bd. This PR now integrates that main revision inb7d92bb60c4769a00c320e2b9aece385ea4b2767; the original Telegram head82b55eafremains in its ancestry. The 400 merge conflicts were resolved from source contracts and all generated outputs were rebuilt.Resulting behavior
cloud.verifiedis false. Install wording directs users to the current files; updating and checking the older cloud theme is a separate owner step. No cloud upload, credential setup or publication-hook activation is part of this integration.Preservation and verification
The integration audit confirms that every preexisting resolved token remains identical to merged main in all three profiles. Only the four accepted Telegram roles/primitives are added. All 57 preexisting non-Telegram distribution artifacts, all 83 Windows files outside its three metadata contracts, and the optimized template, JSON-record, usage and capability helpers are byte-identical to main. Windows changes are limited to complete classification and the regenerated token digest. Both historical Telegram acceptance/import records are unchanged.
At
b7d92bb60c4769a00c320e2b9aece385ea4b2767:Historical evidence and remaining import limits
The original
82b55eafTelegram port was accepted on 2026-10-06 using the Theme Editor and cloud link on Android 12.10.6 and Desktop 7.2.9 on Windows. The owner confirmed visual appearance, cloud application and automatic updates. The exact records remain underports/telegram/evidence/; they describe the prior 3.1.0 subject, not the regenerated files here.That original candidate passed source generation/validation/drift checks, its source suite (385 passed, zero failed, 52 existing skips), build/distribution/smoke, PR CI and hosted whole-suite verification. Earlier token-change runs and r1–r14 reviews remain historical; r14 approved the prior subject and requested the decision-order correction now included.
Current client reimport acceptance has not been performed. Direct file opening, Linux/macOS Desktop, incoming-message selection, and rich-editor/code-block selection remain unexercised. Verification and cloud promotion require renewed imports/checks on both clients; the merge keeps the port experimental.
The owner explicitly authorized merging #69, then #70, with verification on 2026-10-11. The integration uses a normal fast-forward update of the PR branch and preserves its history.
Merge and final main verification
Merged after #69 on 2026-10-11 as
4438fa5900fdfb1e54d4c2e8c98fe8d2e572ccce. Its parents are merged #69 and the reviewed integration candidate, and the final merged tree is identical to that candidate.Final main CI and Pages deployment passed on attempt 2. Sources, Windows lifecycle/native checks, build/smoke, all seven browser shards, packed consumers, combined execution evidence, the release gate and Pages deployment passed. Telegram publication jobs were skipped; the publisher remains disabled.
The first main attempt failed the unchanged checkbox Space-activation test in desktop shard 1/4: focus was established and the key was sent, but the native input remained unchecked. The trace and original failure are retained. The checkbox implementation/test and relevant page runtime are unchanged, and this test passed in both exact-candidate premerge runs. One bounded recheck of that shard and dependent jobs passed with unchanged source, assertions, browser configuration, worker count and deadlines. The exact cause of the first native activation failure remains unidentified; the original failure is not relabelled as a pass.
All 59 published port files were fetched from the deployed site and matched the merged Git artifacts byte for byte, including both new Telegram files. The integration worktree is clean and the five inherited canonical edits retain their original hashes. No new client-import acceptance, fresh Windows theme installation, release tag or Telegram cloud publication was performed.