fix: saving hide premium statuses to config file

fix: possible translator crash
fix: possible AyuForward crash
2026-07-26 07:22:12 +00:00 · 2026-07-02 18:03:27 +03:00 · 2026-07-02 16:53:53 +03:00 · 2026-07-02 16:53:53 +03:00 · 2026-07-02 16:53:53 +03:00 · 2026-07-02 16:50:55 +03:00
2265 changed files with 238065 additions and 56840 deletions
@@ -0,0 +1,559 @@
+# Phase Prompts
+
+Use these templates as Codex subagent messages. Use them as same-session checklists only for Phase 0, intentional main-session build work, Phase 7, or when delegation is unavailable from the start. Replace `<TASK>`, `<PROJECT>`, `<LETTER>`, and `<REPO_ROOT>`.
+
+## Orchestration Rules
+
+- Phase 0 runs in the main session.
+- When delegation is available, use a fresh subagent for Phase 1, Phase 2, Phase 3, each Phase 4 implementation unit, and each Phase 6 pass. Do not switch those phases to same-session midstream because of a timeout or missing artifact.
+- Phase 7 runs in the main session on Windows because it depends on the final local diff and touched-file set.
+- Write each phase prompt to `.ai/<PROJECT>/<LETTER>/logs/phase-<name>.prompt.md` before execution.
+- If you delegate a phase, send the prompt file contents as the initial `spawn_agent` message.
+- When writing the phase prompt file, append the standard progress file contract and the standard compact reply block below so the subagent knows how to surface progress before the final artifact.
+- After each phase completes, write `.ai/<PROJECT>/<LETTER>/logs/phase-<name>.result.md` summarizing the status, files touched, and any follow-up notes.
+- Use `fork_context: false` by default. If the phase depends on thread-only context or UI attachments, pass that context explicitly or enable `fork_context` only for that phase.
+- Prefer `worker` for phases that write files. Use `default` for plan or review passes if that fits the host better. Use `explorer` only for narrow read-only questions.
+- When supported, request `model: gpt-5.4` and `reasoning_effort: xhigh` for delegated phases.
+- Default wait budget for delegated phases is 5 minutes while the phase is clearly still in progress. Successful completion may wake earlier, so this does not delay finished work.
+- When a phase appears close to landing, use 1-2 minute waits until it finishes.
+- A `wait_agent` timeout is not failure. On timeout, inspect both the expected artifact and the matching progress file before deciding anything.
+- If the expected artifact exists and shows progress, wait again.
+- If the expected artifact is not ready but the progress file mtime moved or its heartbeat counter increased since the previous check, wait again. Prefer mtime checks first and avoid rereading the file unless you need detail. Do not count that as a failed wait.
+- If neither the expected artifact nor the progress file moved since the previous blocked check, send one short follow-up asking the same agent to refresh the progress file, finish the required artifact, and return the standard compact reply block, then wait again.
+- If the same agent still produces no usable artifact and no meaningful progress-file movement after two full default waits and one follow-up, close it and retry the phase in a fresh subagent.
+- For Phase 1, Phase 2, Phase 3, Phase 4, and Phase 6, if delegated retries still fail, stop and ask the user rather than rerunning the phase locally.
+- Never use `codex exec`, background shell child processes, or JSONL child-session logging from this skill.
+
+## Standard Progress File Contract
+
+Append this verbatim to every delegated phase prompt:
+
+```text
+Before deep work, create or update the matching progress file in `.ai/<PROJECT>/<LETTER>/logs/`.
+
+Use `<phase-name>.progress.md` as a concise heartbeat with:
+- `Heartbeat: <N>` on the first line, incremented on each meaningful update
+- Current step
+- Files being read or edited
+- Concrete findings or decisions so far
+- Blocker or next checkpoint
+
+Update it sparingly: preferably at natural milestones, and otherwise only after a longer quiet stretch such as roughly 5-10 minutes.
+Keep it tiny so the parent can usually rely on file mtime or the heartbeat counter instead of rereading the whole file.
+Do not wait until the final artifact to write progress.
+```
+
+## Standard Compact Reply Block
+
+Append this verbatim to every delegated phase prompt:
+
+```text
+Before replying in chat, write the required artifact(s) to disk.
+
+Reply in 8 lines or fewer using exactly these keys:
+STATUS: <DONE|BLOCKED|APPROVED|NEEDS_CHANGES>
+ARTIFACTS: <paths>
+TOUCHED: <repo paths or none>
+BLOCKER: <none or one short line>
+
+Do not restate the full context, plan, diff, or long reasoning in the chat reply.
+```
+
+## Artifact-Based Completion Checks
+
+- Phase 1 is complete only when `about.md` and `context.md` both exist and are non-empty.
+- Phase 2 is complete only when `plan.md` exists, contains a `## Status` section, and no unintended source edits were made.
+- Phase 3 is complete only when `plan.md` contains both `Phases:` in the Status section and `Assessed: yes`.
+- Phase 4 is complete only when the target phase checkbox changed to checked and the touched-file list matches the owned write set, or the blocker explains any mismatch.
+- Phase 5 is complete only when the build outcome is known and the build checkbox is updated on success.
+- Phase 6a is complete only when `review<R>.md` exists and contains a verdict line.
+- Phase 6b is complete only when the requested fixes were applied and the post-fix build outcome is known.
+
+## Phase 0: Setup
+
+Record the current time now and store it as `$START_TIME`. You will use this at the end to display total elapsed time.
+
+Before running any phase prompts, determine whether this is a new project or a follow-up task.
+
+Follow-up detection:
+1. Extract the first word or token from the task description. Call it `FIRST_TOKEN`.
+2. Check `.ai/` to see existing project names.
+3. Check whether `.ai/<FIRST_TOKEN>/about.md` exists.
+4. If the file exists, this is a follow-up task. The project name is `FIRST_TOKEN`. The task description is everything after `FIRST_TOKEN`.
+5. If the file does not exist, this is a new project. The full input is the task description.
+
+Do not proceed until you have determined follow-up vs new.
+
+For new projects:
+- Using the list of existing projects, pick a unique short name (1-2 lowercase words, hyphen-separated) that does not collide.
+- Create `.ai/<PROJECT>/`, `.ai/<PROJECT>/a/`, and `.ai/<PROJECT>/a/logs/`.
+- Set `<LETTER>` = `a`.
+
+For follow-up tasks:
+- Scan `.ai/<PROJECT>/` for existing task folders (`a/`, `b/`, ...). Find the latest one (highest letter).
+- The previous task letter = that highest letter.
+- The new task letter = next letter in sequence.
+- Create `.ai/<PROJECT>/<LETTER>/` and `.ai/<PROJECT>/<LETTER>/logs/`.
+
+Then proceed to Phase 1. Follow-up tasks do not skip context gathering. They use a modified Phase 1F prompt.
+
+## Phase 1: Context (New Project, letter = `a`)
+
+```text
+You are a context-gathering agent for a large C++ codebase (Telegram Desktop).
+
+TASK: <TASK>
+
+YOUR JOB: Read AGENTS.md, inspect the codebase, find all files and code relevant to this task, and write two documents.
+
+Steps:
+1. Read AGENTS.md for project conventions and build instructions.
+2. Search the codebase for files, classes, functions, and patterns related to the task.
+3. Read all potentially relevant files. Be thorough and prefer reading more rather than less.
+4. For each relevant file, note:
+   - file path
+   - relevant line ranges
+   - what the code does and how it relates to the task
+   - key data structures, function signatures, and patterns used
+5. Look for similar existing features that could serve as a reference implementation.
+6. Check api.tl if the task involves Telegram API.
+7. Check .style files if the task involves UI.
+8. Check lang.strings if the task involves user-visible text.
+
+Write two files.
+
+File 1: .ai/<PROJECT>/about.md
+
+This file is not used by any agent in the current task. It exists solely as a starting point for a future follow-up task's context gatherer. No planning, implementation, or review phase should rely on it during the current task.
+
+Write it as if the project is already fully implemented and working. It should contain:
+- Project: What this project does (feature description, goals, scope)
+- Architecture: High-level architectural decisions, which modules are involved, how they interact
+- Key Design Decisions: Important choices made about the approach
+- Relevant Codebase Areas: Which parts of the codebase this project touches, key types and APIs involved
+
+Do not include temporal state like "Current State", "Pending Changes", "Not yet implemented", or "TODO". Describe the project as a complete, coherent whole.
+
+File 2: .ai/<PROJECT>/a/context.md
+
+This is the primary task-specific implementation context. All downstream phases should be able to work from this file plus the referenced source files. It must be self-contained. Include:
+- Task Description: The full task restated clearly
+- Relevant Files: Every file path with line ranges and descriptions
+- Key Code Patterns: How similar things are done in the codebase, with snippets when useful
+- Data Structures: Relevant types, structs, classes
+- API Methods: Any TL schema methods involved, copied from api.tl when useful
+- UI Styles: Any relevant style definitions
+- Localization: Any relevant string keys
+- Build Info: Build command and any special notes
+- Reference Implementations: Similar features that can serve as templates
+
+Be extremely thorough. Another agent with no prior context will rely on this file.
+
+Do not implement code in this phase.
+```
+
+## Phase 1F: Context (Follow-up Task, letter = `b`, `c`, ...)
+
+```text
+You are a context-gathering agent for a follow-up task on an existing project in a large C++ codebase (Telegram Desktop).
+
+NEW TASK: <TASK>
+
+YOUR JOB: Read the existing project state, gather any additional context needed, and produce fresh documents for the new task.
+
+Steps:
+1. Read AGENTS.md for project conventions and build instructions.
+2. Read .ai/<PROJECT>/about.md. This is the project-level blueprint describing everything done so far.
+3. Read .ai/<PROJECT>/<PREV_LETTER>/context.md. This is the previous task's gathered context.
+4. Understand what has already been implemented by reading the actual source files referenced in about.md and the previous context.
+5. Based on the new task description, search the codebase for any additional files, classes, functions, and patterns that are relevant to the new task but not already covered.
+6. Read all newly relevant files thoroughly.
+
+Write two files.
+
+File 1: .ai/<PROJECT>/about.md (rewrite)
+
+Rewrite this file instead of appending to it. The new about.md must be a single coherent document that describes the project as if everything, including this new task's changes, is already fully implemented and working.
+
+It should incorporate:
+- everything from the old about.md that is still accurate and relevant
+- the new task's functionality described as part of the project, not as a pending change
+- any changed design decisions or architectural updates from the new task requirements
+
+It should not contain:
+- temporal state such as "Current State", "Pending Changes", or "TODO"
+- history of how requirements changed between tasks
+- references to "the old approach" versus "the new approach"
+- task-by-task changelog or timeline
+- information that contradicts the new task requirements
+
+File 2: .ai/<PROJECT>/<LETTER>/context.md
+
+This is the primary document for the new task. It must be self-contained and should include:
+- Task Description: The new task restated clearly, with enough project background that an implementation agent can understand it without reading any other .ai files
+- Relevant Files: Every file path with line ranges relevant to this task
+- Key Code Patterns: How similar things are done in the codebase
+- Data Structures: Relevant types, structs, classes
+- API Methods: Any TL schema methods involved
+- UI Styles: Any relevant style definitions
+- Localization: Any relevant string keys
+- Build Info: Build command and any special notes
+- Reference Implementations: Similar features that can serve as templates
+
+Be extremely thorough. Another agent with no prior context should be able to work from this file alone.
+
+Do not implement code in this phase.
+```
+
+## Phase 2: Plan
+
+```text
+You are a planning agent. You must create a detailed implementation plan.
+
+Read these files:
+- .ai/<PROJECT>/<LETTER>/context.md
+- Then read the specific source files referenced in context.md to understand the code deeply.
+
+Create a detailed plan in: .ai/<PROJECT>/<LETTER>/plan.md
+
+The plan.md should contain:
+
+## Task
+<one-line summary>
+
+## Approach
+<high-level description of the implementation approach>
+
+## Files to Modify
+<list of files that will be created or modified>
+
+## Files to Create
+<list of new files, if any>
+
+## Implementation Steps
+
+Each step must be specific enough that an agent can execute it without ambiguity:
+- exact file paths
+- exact function names
+- what code to add, modify, or remove
+- where exactly in the file (after which function, in which class, and so on)
+
+Number every step. Group steps into phases if there are more than about eight steps.
+
+### Phase 1: <name>
+1. <specific step>
+2. <specific step>
+
+### Phase 2: <name> (if needed)
+1. <specific step>
+
+## Build Verification
+- build command to run
+- expected outcome
+
+## Status
+- [ ] Phase 1: <name>
+- [ ] Phase 2: <name> (if applicable)
+- [ ] Build verification
+- [ ] Code review
+
+Do not implement code in this phase.
+```
+
+## Phase 3: Plan Assessment
+
+```text
+You are a plan assessment agent. Review and refine an implementation plan.
+
+Read these files:
+- .ai/<PROJECT>/<LETTER>/context.md
+- .ai/<PROJECT>/<LETTER>/plan.md
+- Then read the actual source files referenced to verify the plan makes sense.
+
+Assess the plan:
+
+1. Correctness: Are the file paths and line references accurate? Does the plan reference real functions and types?
+2. Completeness: Are there missing steps? Edge cases not handled?
+3. Code quality: Will the plan minimize code duplication? Does it follow existing codebase patterns from AGENTS.md?
+4. Design: Could the approach be improved? Are there better patterns already used in the codebase?
+5. Phase sizing: Each phase should be implementable by a single agent in one session. If a phase has more than about 8-10 substantive code changes, split it further.
+
+Update plan.md with your refinements. Keep the same structure but:
+- fix any inaccuracies
+- add missing steps
+- improve the approach if you found better patterns
+- ensure phases are properly sized for single-agent execution
+- add a line at the top of the Status section: `Phases: <N>`
+- add `Assessed: yes` at the bottom of the file
+
+If the plan is small enough for a single agent (roughly 8 steps or fewer), mark it as a single phase.
+
+Do not implement code in this phase.
+```
+
+## Phase 4: Implementation
+
+Run one implementation unit per plan phase. Keep implementation phases sequential by default. Parallelize only if their write sets are disjoint and the plan makes that safe.
+
+For each phase in the plan that is not yet marked as done, use this prompt:
+
+```text
+You are an implementation agent working on phase <N> of an implementation plan.
+
+Read these files first:
+- .ai/<PROJECT>/<LETTER>/context.md
+- .ai/<PROJECT>/<LETTER>/plan.md
+
+Then read the source files you will be modifying.
+
+Your owned write set for this phase:
+<OWNED_WRITE_SET>
+
+YOUR TASK: Implement only Phase <N> from the plan:
+<paste the specific phase steps here>
+
+Rules:
+- Follow the plan precisely.
+- Follow AGENTS.md coding conventions.
+- You are not alone in the codebase. Respect existing changes and do not revert unrelated work.
+- Do not modify .ai/ files except to update the Status section in plan.md.
+- When done, update plan.md Status section: change `- [ ] Phase <N>: ...` to `- [x] Phase <N>: ...`
+- Do not work on other phases.
+
+When finished, report what you did, which files you changed, and any issues encountered.
+```
+
+After each implementation phase:
+1. Use a narrow read or search to confirm the status line was updated.
+2. Verify the owned write set and touched files with a small diff summary such as `git diff --name-only`.
+3. If more phases remain, run the next implementation phase.
+4. If all phases are done, proceed to build verification.
+
+## Phase 5: Build Verification
+
+Only run this phase if the task modified project source code.
+
+Prefer running the build in the main session because it is critical-path work. If you delegate it, use a worker subagent and wait immediately for the result.
+
+```text
+You are a build verification agent.
+
+Read these files:
+- .ai/<PROJECT>/<LETTER>/context.md
+- .ai/<PROJECT>/<LETTER>/plan.md
+
+The implementation is complete. Your job is to build the project and fix any build errors that block the planned work.
+
+Steps:
+1. Run (from repository root): cmake --build ./out --config Debug --target Telegram
+2. If the build succeeds, update plan.md: change `- [ ] Build verification` to `- [x] Build verification`
+3. If the build fails:
+   a. Read the error messages carefully
+   b. Read the relevant source files
+   c. Fix the errors in accordance with the plan and AGENTS.md conventions
+   d. Rebuild and repeat until the build passes
+   e. Update plan.md status when done
+
+Rules:
+- Only fix build errors. Do not refactor or improve code beyond what is needed for a passing build.
+- Follow AGENTS.md conventions.
+- If build fails with file-locked errors (C1041, LNK1104, "cannot open output file", or similar access-denied lock issues), stop and report the lock. Do not retry.
+- You are not alone in the codebase. Respect existing changes and do not revert unrelated work.
+
+When finished, report the build result and which files, if any, you changed.
+```
+
+## Phase 6: Code Review Loop
+
+After build verification passes, run up to 3 review-fix iterations. Set iteration counter `R = 1`.
+
+Review loop:
+
+```text
+LOOP:
+  1. Run review phase 6a with iteration R.
+  2. Read review<R>.md verdict:
+     - "APPROVED" -> go to FINISH
+     - "NEEDS_CHANGES" -> run fix phase 6b
+  3. After fix work completes and build passes:
+     R = R + 1
+     If R > 3 -> go to FINISH
+     Otherwise -> go to step 1
+
+FINISH:
+  - Update plan.md: change `- [ ] Code review` to `- [x] Code review`
+  - Proceed to Phase 7 on Windows, otherwise proceed to Completion
+```
+
+### Step 6a: Code Review
+
+```text
+You are a code review agent for Telegram Desktop (C++ / Qt).
+
+Read these files:
+- .ai/<PROJECT>/<LETTER>/context.md
+- .ai/<PROJECT>/<LETTER>/plan.md
+- REVIEW.md
+- If R > 1, also read .ai/<PROJECT>/<LETTER>/review<R-1>.md
+
+Then run `git diff` to see the current uncommitted changes for this task.
+
+Read the modified source files in full to understand the changes in context.
+
+Perform a focused code review using these criteria, in order:
+
+1. Correctness and safety: Obvious logic errors, missing null checks at API boundaries, potential crashes, use-after-free, dangling references, race conditions.
+2. Dead code: Added or left-behind code that is never used within the scope of the changes.
+3. Redundant changes: Diff hunks that have no functional effect.
+4. Code duplication: Repeated logic that should be shared.
+5. Wrong placement: Code added to a module where it does not logically belong.
+6. Function decomposition: Whether an extracted helper would clearly improve readability.
+7. Module structure: Only in exceptional cases where a large new chunk of code clearly belongs elsewhere.
+8. Style compliance: REVIEW.md rules and AGENTS.md conventions.
+
+Important guidelines:
+- Review only the changes made, not pre-existing code outside the scope of the task.
+- Be pragmatic. Each suggestion should have a clear, concrete benefit.
+- Do not suggest comments, docstrings, or over-engineering.
+
+Write your review to: .ai/<PROJECT>/<LETTER>/review<R>.md
+
+The review document should contain:
+
+## Code Review - Iteration <R>
+
+## Summary
+<1-2 sentence overall assessment>
+
+## Verdict: <APPROVED or NEEDS_CHANGES>
+
+If the verdict is NEEDS_CHANGES, continue with:
+
+## Changes Required
+
+### <Issue 1 title>
+- Category: <dead code | duplication | wrong placement | function decomposition | module structure | style | correctness>
+- File(s): <file paths>
+- Problem: <clear description>
+- Fix: <specific description of what to change>
+
+Keep the list focused. Prioritize the most impactful issues.
+
+When finished, report your verdict clearly as: APPROVED or NEEDS_CHANGES.
+```
+
+### Step 6b: Review Fix
+
+```text
+You are a review fix agent. You implement improvements identified during code review.
+
+Read these files:
+- .ai/<PROJECT>/<LETTER>/context.md
+- .ai/<PROJECT>/<LETTER>/plan.md
+- .ai/<PROJECT>/<LETTER>/review<R>.md
+
+Then read the source files mentioned in the review.
+
+YOUR TASK: Implement all changes listed in review<R>.md.
+
+Rules:
+- Implement exactly the review changes, nothing more.
+- Follow AGENTS.md coding conventions.
+- You are not alone in the codebase. Respect existing changes and do not revert unrelated work.
+- Do not modify .ai/ files except where the review process explicitly requires it.
+
+After all changes are made:
+1. Build (from repository root): cmake --build ./out --config Debug --target Telegram
+2. If the build fails, fix build errors and rebuild until it passes.
+3. If build fails with file-locked errors (C1041, LNK1104, "cannot open output file", or similar access-denied lock issues), stop and report the lock. Do not retry.
+
+When finished, report what changes were made and which files you touched.
+```
+
+## Phase 7: Windows Text Normalization
+
+Run this phase only on Windows hosts and only after the review loop has finished.
+
+Use the current task's result logs as the source of truth for what Codex touched. Do not sweep the whole repo and do not rewrite unrelated files from a dirty worktree.
+
+```text
+You are performing the final Windows-only text normalization phase for task-think.
+
+Read these files:
+- .ai/<PROJECT>/<LETTER>/plan.md
+- .ai/<PROJECT>/<LETTER>/logs/phase-4*.result.md
+- .ai/<PROJECT>/<LETTER>/logs/phase-5*.result.md
+- .ai/<PROJECT>/<LETTER>/logs/phase-6*.result.md
+
+Your job:
+- Collect the union of repo file paths listed under "Touched files" in those result logs.
+- Keep only files inside the repository that currently exist and are textual project files: source, headers, build/config files, localization files, style files, and similar text assets.
+- Exclude `.ai/`, `out/`, binary files, and unrelated user files that were not touched by Codex in this task.
+- Rewrite each kept file so all line endings are CRLF.
+- If a kept file is UTF-8 or ASCII text, write it back as UTF-8 without BOM. Never add a UTF-8 BOM to source/config/project text files.
+- Preserve file content otherwise. Preserve whether the file ended with a trailing newline.
+
+Rules:
+- Run this phase in the main session on Windows.
+- Do not modify files outside the touched-file set for the current task.
+- Do not rewrite binary files.
+- When scripting this phase, do not use writer APIs or defaults that emit UTF-8 with BOM.
+- If a file cannot be normalized safely, record it as a failure instead of silently skipping it.
+
+When finished:
+1. Write `.ai/<PROJECT>/<LETTER>/logs/phase-7-line-endings.result.md`
+2. Include:
+   - whether the phase completed
+   - which files were normalized
+   - which files were skipped and why
+   - whether any UTF-8 BOMs were removed or verified absent
+   - any failures that need to be mentioned in the final summary
+```
+
+## Completion
+
+When all phases, including build verification, code review, and Windows line ending normalization when applicable, are done:
+1. Read the final `plan.md` and report the summary to the user.
+2. Show which files were modified or created.
+3. Note any issues encountered during implementation.
+4. Summarize the code review iterations: how many rounds, what was found and fixed, or whether it was approved on the first pass.
+5. On Windows, mention the text-normalization result briefly: which project files were normalized, whether any BOMs were removed, or whether nothing needed changes.
+6. Calculate and display the total elapsed time since `$START_TIME` (format as `Xh Ym Zs`, omitting zero components).
+7. Remind the user of the project name so they can request follow-up tasks within the same project.
+
+## Error Handling
+
+- If any phase fails or gets stuck, follow the timeout and retry rules above. Do not close an agent solely because the final artifact is missing while its progress file is still advancing. For Phase 1, Phase 2, Phase 3, Phase 4, and Phase 6, do not rerun locally after delegated retries fail; ask the user instead.
+- If `context.md` or `plan.md` is not written properly by a phase, rerun that phase in a fresh subagent with more specific instructions.
+- If build errors persist after the build phase's attempts, report the remaining errors to the user.
+- If a review-fix phase introduces new build errors that it cannot resolve, report to the user.
+
+## Prompt Delivery And Logs
+
+For each phase:
+1. Write the full prompt to `.ai/<PROJECT>/<LETTER>/logs/phase-<name>.prompt.md`
+2. Delegate by sending that prompt text to a fresh subagent, or use it as a same-session checklist only for the designated main-session phases or when delegation was unavailable from the start
+3. For delegated phases, expect a matching `.ai/<PROJECT>/<LETTER>/logs/phase-<name>.progress.md` heartbeat while work is in flight
+4. Save a concise completion note to `.ai/<PROJECT>/<LETTER>/logs/phase-<name>.result.md`
+
+For review iterations, include the iteration in the file name, for example:
+- `phase-6a-review-1.prompt.md`
+- `phase-6a-review-1.result.md`
+- `phase-6b-fix-1.prompt.md`
+- `phase-6b-fix-1.result.md`
+
+## Subagent Pattern
+
+Use this pattern conceptually for delegated phases:
+
+1. Write the phase prompt file.
+2. Spawn a fresh subagent with the phase prompt, usually with `fork_context: false`.
+3. Require the agent to create the matching progress file early and refresh it sparingly: at natural milestones when possible, otherwise only after a longer quiet stretch such as roughly 5-10 minutes.
+4. Wait in 5-minute intervals when the next step is blocked on that phase, checking both the final artifact and the progress file on timeout.
+5. When the phase looks close to finishing, switch to 1-2 minute waits.
+6. Prefer filesystem mtime checks on the progress file first. If its mtime moved or the heartbeat counter increased, keep waiting; do not treat that as a stall.
+7. If neither the artifact nor the progress file moves, send one short follow-up to the same agent, then retry once with a fresh subagent before involving the user.
+8. Validate the expected artifact or code changes with small shell summaries and the completion checks above.
+9. Write the result log from the validated outcome and the compact reply block.
+
+Do not replace this pattern with shell-launched `codex exec`.
@@ -0,0 +1,145 @@
+---
+name: task-think
+description: Orchestrate a multi-phase implementation workflow for this repository with artifact files under .ai/<project-name>/<letter>/ using Codex subagents instead of shell-spawned child processes. Use when the user wants one prompt to drive context gathering, planning, plan assessment, implementation, build verification, and review with persistent artifacts, clear phase handoffs, and a thin parent thread. Prefer spawn_agent/send_input/wait_agent, keep heavy pre-build work delegated when possible, and avoid pulling timed-out phases back into the main session.
+---
+
+# Task Pipeline
+
+Run a full implementation workflow with repository artifacts and clear phase boundaries.
+
+## Inputs
+
+Collect:
+- task description
+- optional project name (if missing, derive a short kebab-case name)
+- optional constraints (files, architecture, risk tolerance)
+- optional screenshot paths
+
+If screenshots are attached in UI but not present as files, write a brief textual summary into the task artifacts before spawning fresh subagents so later phases can read the requirements without inheriting the whole parent thread.
+
+## Overview
+
+The workflow is organized around projects. Each project lives in `.ai/<project-name>/` and can contain multiple sequential tasks (labeled `a`, `b`, `c`, ... `z`).
+
+Project structure:
+```text
+.ai/<project-name>/
+  about.md              # Single source of truth for the entire project
+  a/                    # First task
+    context.md          # Gathered codebase context for this task
+    plan.md             # Implementation plan
+    review1.md          # Code review documents (up to 3 iterations)
+    review2.md
+    review3.md
+    logs/
+      phase-*.prompt.md
+      phase-*.progress.md
+      phase-*.result.md
+  b/                    # Follow-up task
+    context.md
+    plan.md
+    review1.md
+    logs/
+      ...
+  c/                    # Another follow-up task
+    ...
+```
+
+- `about.md` is the project-level blueprint: a single comprehensive document describing what this project does and how it works, written as if everything is already fully implemented. It contains no temporal state ("current state", "pending changes", "not yet implemented"). It is rewritten, not appended to, each time a new task starts, incorporating the new task's changes as if they were always part of the design.
+- Each task folder (`a/`, `b/`, ...) contains self-contained files for that task. The task's `context.md` carries all task-specific information: what specifically needs to change, the delta from the current codebase, gathered file references, and code patterns. Planning, implementation, and review phases should rely on the current task folder.
+
+## Artifacts
+
+Create and maintain:
+- `.ai/<project-name>/about.md`
+- `.ai/<project-name>/<letter>/context.md`
+- `.ai/<project-name>/<letter>/plan.md`
+- `.ai/<project-name>/<letter>/review<R>.md` (up to 3 review iterations)
+- `.ai/<project-name>/<letter>/logs/phase-<name>.prompt.md`
+- `.ai/<project-name>/<letter>/logs/phase-<name>.progress.md` for delegated phases
+- `.ai/<project-name>/<letter>/logs/phase-<name>.result.md`
+
+Each `phase-<name>.result.md` should capture a concise outcome summary: whether the phase completed, which files it touched, and any follow-up notes or blockers.
+Each delegated `phase-<name>.progress.md` should act as a heartbeat: a tiny monotonic counter plus current step, files being read or edited, concrete findings so far, and the next checkpoint. It is not a final artifact; it exists so the parent can distinguish active research from a truly stuck subagent without rereading large context.
+
+## Phases
+
+Run these phases sequentially:
+
+1. Phase 0: Setup - Record start time, detect follow-up vs new project, create directories.
+2. Phase 1: Context Gathering - Read codebase, write `about.md` and `context.md`. Use Phase 1F for follow-up tasks.
+3. Phase 2: Planning - Read context, write detailed `plan.md` with numbered steps grouped into phases.
+4. Phase 3: Plan Assessment - Review and refine the plan for correctness, completeness, code quality, and phase sizing.
+5. Phase 4: Implementation - Execute one implementation unit per plan phase.
+6. Phase 5: Build Verification - Build the project, fix any build errors. Skip if no source code was modified.
+7. Phase 6: Code Review Loop - Run review and fix iterations until approved or the iteration limit is reached.
+8. Phase 7: Windows Text Normalization - On Windows only, after review passes and before the final summary, normalize LF to CRLF for the text source/config files Codex edited in this task and ensure rewritten UTF-8 project files are saved without BOM.
+
+Use the phase prompt templates in `PROMPTS.md`.
+
+## Execution Mode
+
+Use Codex subagents as the primary orchestration mechanism.
+
+- When delegation is available, Phase 1, Phase 2, Phase 3, each Phase 4 implementation unit, and each Phase 6 review or review-fix pass must run in fresh subagents. Do not rerun those phases in the main session midstream just because a wait timed out or an artifact is missing.
+- Run Phase 7 in the main session on Windows because it depends on the final local file state and the exact touched-file set for the current task.
+- When any same-session helper rewrites Windows project text files, preserve CRLF and write UTF-8 without BOM. Avoid writer APIs or defaults that silently inject a UTF-8 BOM.
+- The main session may read `context.md` once after Phase 1 and `plan.md` once after Phase 3. After that, prefer narrow shell checks, file existence checks, and status-line reads instead of rereading full documents or diffs.
+- Prefer `worker` for phases that write files. Use `explorer` only for narrow read-only questions that unblock your next local step.
+- Keep `fork_context` off by default. Pass the phase prompt and explicit file paths instead of the whole thread unless the phase truly needs prior conversational context or thread-only attachments.
+- When the platform supports it, request `model: gpt-5.4` and `reasoning_effort: xhigh` for spawned phase agents. If overrides are unavailable, inherit the current session settings.
+- Write the exact phase prompt to the matching `logs/phase-<name>.prompt.md` file before you delegate. Use the same prompt file as a checklist if you later need to fall back to same-session execution.
+- For delegated phases, require an early `logs/phase-<name>.progress.md` heartbeat before deep work. The subagent should create or update it early, keep it tiny, and refresh it sparingly: preferably at natural milestones, and otherwise only after a longer quiet stretch such as roughly 5-10 minutes.
+- In every delegated prompt, require a compact final reply with only status, artifact paths, touched files, and blocker or `none`. Detailed reasoning belongs in `.ai/` artifacts, not in the chat reply.
+- After a subagent finishes, verify that the expected artifacts or code changes exist, then write a short result log in `logs/phase-<name>.result.md`.
+- For delegated phases, use `wait_agent` with a 5-minute timeout by default while a phase is still clearly in progress. Successful completion may wake earlier, so this does not add latency to finished phases.
+- When a phase looks close to completion — for example the final artifact has appeared, a build is in its final pass, or the agent said it is wrapping up — switch to 1-2 minute waits until it lands.
+- A timeout is not a failure; it only means no final status arrived yet. Do not treat short waits as stall detection for research-heavy phases.
+- On timeout, inspect the expected artifact, the phase progress file mtime, and the worktree for movement. Prefer mtime checks first; only reread the progress file when you need detail.
+- If the progress file mtime moved or its heartbeat counter increased since the previous check, treat that as active progress and wait again.
+- If no usable final artifact exists yet but the progress file is appearing or advancing, keep the same subagent alive. Progress-file movement does not count toward the retry limit.
+- If no usable final artifact exists yet and neither the expected artifact nor the progress file has moved since the previous blocked check, send one short follow-up asking the same subagent to refresh the progress file, finish the artifact, and return the compact status block, then wait again.
+- Only if the same subagent still shows no meaningful movement in either the expected artifact or the progress file after two full default waits and one follow-up should you close it and rerun that phase in a fresh subagent.
+- Use `wait_agent` only when the next step is blocked on the result. While the delegated phase runs, do small non-overlapping local tasks such as validating directory structure or preparing the next prompt file.
+- Build verification is critical-path work. Prefer running the build in the main session, and only delegate a bounded build-fix phase when there is a concrete reason.
+- If subagents are unavailable in the current environment, or current policy does not allow delegation from the start, run the phase in the main session using the same prompt files. Otherwise, do not switch a pre-build phase to same-session midstream. Never fall back to shell-spawned `codex exec` child processes from this skill.
+
+## Verification Rules
+
+- If build or test commands fail due to file locks or access-denied outputs (C1041, LNK1104), stop and ask the user to close locking processes before retrying.
+- Treat a delegated phase as complete only when the required artifact or status update exists on disk and matches the phase goals; do not rely on the chat reply alone.
+- Never claim completion without:
+  - implemented code changes present
+  - build attempt results recorded
+  - review pass documented with any follow-up fixes
+  - on Windows, if the task edited project source/config text files, a CRLF / no-BOM normalization pass recorded after review
+
+## Completion Criteria
+
+Mark complete only when:
+- All plan phases are done
+- Build verification is recorded
+- Review issues are addressed or explicitly deferred with rationale
+- On Windows, Codex-edited project source/config text files have been normalized to CRLF, any UTF-8 rewrites were saved without BOM, and the result is logged
+- Display total elapsed time since start (format: `Xh Ym Zs`, omitting zero components)
+- Remind the user of the project name so they can request follow-up tasks within the same project
+
+## Error Handling
+
+- If any phase fails, times out, or gets stuck, follow the retry ladder from Execution Mode. Do not close an agent solely because the final artifact is missing while its progress file is still moving. After two delegated attempts remain blocked with no meaningful progress, report the issue to the user. Do not absorb the phase into the main session before build unless delegation was unavailable from the start.
+- If `context.md` or `plan.md` is not written properly by a phase, rerun that phase in a fresh subagent with more specific instructions. Do not repair it locally before build unless delegation was unavailable from the start.
+- If build errors persist after the build phase's attempts, report the remaining errors to the user.
+- If a review-fix phase introduces new build errors that it cannot resolve, report to the user.
+- If Phase 7 cannot safely normalize a touched file on Windows or remove an introduced UTF-8 BOM from a touched project text file, record the failure in the result log and report it in the final summary instead of silently skipping it.
+
+## User Invocation
+
+Use plain language with the skill name in the request, for example:
+
+`Use local task-think skill with subagents: make sure FileLoadTask::process does not create or read QPixmap on background threads; use QImage with ARGB32_Premultiplied instead.`
+
+For follow-up tasks on an existing project:
+
+`Use local task-think skill with subagents: my-project also handle the case where the file is already cached`
+
+If screenshots are relevant, include file paths in the same prompt when possible.
@@ -1,57 +0,0 @@
---
-Language: Cpp
-BasedOnStyle: LLVM
-AccessModifierOffset: -4
-AlignConsecutiveAssignments: false
-AlignConsecutiveDeclarations: false
-AlignOperands: false
-AlignTrailingComments: false
-AllowShortCaseLabelsOnASingleLine: true
-AllowShortIfStatementsOnASingleLine: true
-AllowShortLoopsOnASingleLine: true
-AlwaysBreakTemplateDeclarations: Yes
-BinPackArguments: false
-BinPackParameters: false
-BraceWrapping: 
-  AfterCaseLabel: false
-  AfterClass: true
-  AfterControlStatement: false
-  AfterEnum: true
-  AfterFunction: false
-  AfterNamespace: false
-  AfterStruct: true
-  AfterUnion: true
-  AfterExternBlock: true
-  BeforeCatch: false
-  BeforeElse: false
-  BeforeLambdaBody: true
-  BeforeWhile: false
-  SplitEmptyFunction: true
-  SplitEmptyRecord: true
-  SplitEmptyNamespace: true
-BreakBeforeBraces: Custom
-ColumnLimit: 120
-IncludeCategories: 
-  - Regex: '^<.*'
-    Priority: 1
-  - Regex: '^".*'
-    Priority: 2
-  - Regex: '.*'
-    Priority: 3
-IncludeIsMainRegex: '([-_](test|unittest))?$'
-IndentCaseLabels: true
-IndentWidth: 4
-InsertNewlineAtEOF: true
-MacroBlockBegin: ''
-MacroBlockEnd: ''
-MaxEmptyLinesToKeep: 2
-SpaceAfterCStyleCast: true
-SpaceAfterTemplateKeyword: false
-SpaceInEmptyParentheses: false
-SpacesInAngles: false
-SpacesInConditionalStatement: false
-SpacesInCStyleCastParentheses: false
-SpacesInParentheses: false
-TabWidth: 4
-UseTab: Always
-...
@@ -0,0 +1,306 @@
+---
+description: Generate an SVG icon from a design mockup using vectosolve vectorization
+allowed-tools: Read, Write, Edit, Glob, Grep, Bash, Agent, AskUserQuestion, TodoWrite, mcp__vectosolve__vectorize
+---
+
+# Icon - SVG Icon Generation from Design Mockup
+
+You generate production-quality SVG icons for Telegram Desktop by vectorizing design mockup screenshots using the vectosolve MCP service, then post-processing the result to match the Telegram icon format.
+
+**Arguments:** `$ARGUMENTS` = "$ARGUMENTS"
+
+If `$ARGUMENTS` is empty, ask the user to describe the icon they want and paste a cropped screenshot of it.
+
+## Overview
+
+The workflow takes a cropped screenshot of an icon from a design mockup (grabbed from the clipboard), vectorizes it via the vectosolve MCP, then post-processes the SVG (recolor to white-on-transparent, restructure to minimal format, set 24x24 output size).
+
+Working directory: `.ai/icon_{name}/` with iterations labeled by letter (`a/`, `b/`, ...), each containing `source.png`. Output SVGs are in the icon root: `a.svg`, `b.svg`, etc.
+
+Follow-ups are supported: `/icon {icon_name} <description>` continues from where the previous run left off.
+
+## Phase 0: Setup
+
+**Record the current time** (using `date` or equivalent) as `$START_TIME`.
+
+### Step 0a: Clipboard grab (MUST be the VERY FIRST action)
+
+If there is an image attached to the user's message:
+
+1. Generate a random 8-character hex string for `HASH` (use `openssl rand -hex 4` or similar).
+2. **IMMEDIATELY** — before any other processing — run this Bash command to save the clipboard image:
+   ```bash
+   HASH=$(openssl rand -hex 4) && if [[ "$OSTYPE" == darwin* ]]; then bash .claude/grab_clipboard.sh ".ai/icon_${HASH}.png"; else powershell -ExecutionPolicy Bypass -File .claude/grab_clipboard.ps1 ".ai/icon_${HASH}.png"; fi
+   ```
+   On macOS `.claude/grab_clipboard.sh` is used; on Windows `.claude/grab_clipboard.ps1`. Both grab the current clipboard image and save it to the specified path.
+
+3. If the command fails (exit 1 / no image on clipboard):
+   - Tell the user: **"Clipboard doesn't contain an image. Please copy the icon area first, then retry."** (On macOS: Cmd+Ctrl+Shift+4 to snip to clipboard; on Windows: Win+Shift+S.)
+   - **STOP IMMEDIATELY. Do NOT continue.** You cannot use the image pasted in the conversation — it exists only as pixels in the chat, not as a file you can send to vectosolve. The clipboard grab is the ONLY way to get the image to disk. Do not attempt any workaround.
+
+4. Read back the saved `.ai/icon_HASH.png` using the Read tool.
+5. Compare it visually with the image pasted in the conversation. They should depict the same thing.
+   - If they look **completely different**: delete `.ai/icon_HASH.png` and fail:
+     > "The clipboard image doesn't match what you pasted. Please re-copy and retry."
+   - If they look the same (or close enough): proceed. Store the temp path.
+
+If NO image is attached to the message, skip this step entirely.
+
+### Step 0b: Fail-fast — verify vectosolve MCP
+
+Check that the `mcp__vectosolve__vectorize` tool is available by looking at your available tools list. If it is NOT available, fail immediately with:
+
+> vectosolve MCP is not configured. Set it up with:
+> ```
+> claude mcp add vectosolve --scope user -e VECTOSOLVE_API_KEY=vs_xxx -- npx @vectosolve/mcp
+> ```
+> Then restart Claude Code.
+
+### Step 0c: Follow-up detection
+
+Extract the first word/token from `$ARGUMENTS` (everything before the first space or newline). Call it `FIRST_TOKEN`.
+
+Run these TWO commands using the Bash tool, **IN PARALLEL**:
+1. `ls .ai/` — to see all existing icon project names
+2. `ls .ai/icon_{FIRST_TOKEN}/context.md` — to check if this specific icon project exists
+
+**Evaluate the results:**
+- If command 2 **succeeds** (context.md exists): this is a **follow-up**. The icon name is `FIRST_TOKEN`. The follow-up description is everything in `$ARGUMENTS` after `FIRST_TOKEN`.
+- If command 2 **fails** (not found): this is a **new icon**. The full `$ARGUMENTS` is the icon description.
+
+### Step 0d: New icon setup
+
+1. Parse `$ARGUMENTS` to determine:
+   - **Icon description**: what the icon should depict
+   - **Icon type**: default is `menu` (24x24 menu/button icon). User may specify otherwise.
+   - **Target subfolder**: `menu/` by default, or another subfolder if specified.
+
+2. Choose an icon file name:
+   - Lowercase letters and underscores only — **NO hyphens**
+   - Match existing naming conventions (check `Telegram/Resources/icons/{subfolder}/`)
+   - Must NOT conflict with existing icons
+   - Must NOT collide with existing `.ai/icon_{name}/` directories
+
+3. Create `.ai/icon_{name}/` and `.ai/icon_{name}/a/`.
+
+4. Write `.ai/icon_{name}/context.md` with:
+   ```
+   ## Icon: {icon_name}
+   Type: {menu/other}
+   Target: Telegram/Resources/icons/{subfolder}/{icon_name}.svg
+
+   ## Original Request
+   {full $ARGUMENTS text}
+
+   ## Follow-ups
+   (none yet)
+   ```
+
+5. Set `LETTER` to `a`.
+
+### Step 0e: Follow-up setup
+
+1. Read `.ai/icon_{name}/context.md` to get the icon type, subfolder, and full history.
+2. Find the latest existing letter folder in `.ai/icon_{name}/` (highest letter).
+3. Set `LETTER` to the next letter after the latest.
+4. Create `.ai/icon_{name}/{LETTER}/`.
+5. Update `.ai/icon_{name}/context.md` — append the follow-up description to the `## Follow-ups` section:
+   ```
+   ### Follow-up (starting at letter {LETTER})
+   {follow-up description}
+   ```
+
+### Step 0f: Place source image
+
+If a clipboard image was grabbed in Step 0a:
+1. Copy (or move) `.ai/icon_HASH.png` → `.ai/icon_{name}/source.png` (overwrite if exists — this is always the latest source).
+2. Copy it to `.ai/icon_{name}/{LETTER}/source.png` (archive per-iteration source).
+3. Delete the temp `.ai/icon_HASH.png` if it was copied (not moved).
+
+If NO image was grabbed:
+- **New icon with no image**: Ask the user to provide a screenshot. STOP.
+- **Follow-up with no image**: The existing `source.png` in the icon root carries forward. Copy it to `.ai/icon_{name}/{LETTER}/source.png`. If no source.png exists at all, ask the user for an image.
+
+### Step 0g: Verify renderer
+
+Locate the render tool (`codegen_style` with `--render-svg` mode):
+
+```bash
+if [[ "$OSTYPE" == darwin* ]]; then
+    ls out/Telegram/codegen/codegen/style/Debug/codegen_style
+else
+    ls out/Telegram/codegen/codegen/style/Debug/codegen_style.exe
+fi
+```
+
+If missing, build it: `cmake --build out --config Debug --target codegen_style`
+
+Test on a known good SVG (use the appropriate binary path for the OS):
+```bash
+CODEGEN=$(if [[ "$OSTYPE" == darwin* ]]; then echo out/Telegram/codegen/codegen/style/Debug/codegen_style; else echo out/Telegram/codegen/codegen/style/Debug/codegen_style.exe; fi)
+$CODEGEN --render-svg Telegram/Resources/icons/menu/tag_add.svg .ai/icon_{name}/test_render.png 512
+```
+
+If works → delete test render, set `RENDER_AVAILABLE = true`. If fails → `RENDER_AVAILABLE = false`.
+
+## Phase 1: Vectorize & Post-process
+
+### Step 1a: Call vectosolve
+
+Use the `mcp__vectosolve__vectorize` tool with `file_path` set to the **absolute path** of `.ai/icon_{name}/{LETTER}/source.png`.
+
+**If this fails, STOP IMMEDIATELY.** Do NOT try to generate the SVG manually or by any other means. Report the error to the user and let them fix the issue (bad API key, no credits, network error, etc.).
+
+Save the returned SVG content to `.ai/icon_{name}/{LETTER}/raw_vectosolve.svg`.
+
+The MCP tool calls the vectosolve API ($0.20/call). The API key is stored in `~/.claude.json` MCP config (never in the repository).
+
+### Step 1b: Post-process the SVG
+
+The vectosolve SVG will have colors from the mockup, arbitrary dimensions, and possibly a non-square aspect ratio from a non-square screenshot crop. Post-processing fixes this by adjusting the **viewBox** — leave path coordinates untouched.
+
+**Do NOT transform path coordinates.** Vectosolve's paths are correct — the only thing wrong is the framing. All geometry adjustments are done by manipulating the `viewBox` and the `width`/`height` attributes.
+
+#### Sub-step 1: Read the request and determine parameters
+
+Before touching the SVG, determine these from the user's request and context.md:
+
+1. **Output size** (`OUT_W × OUT_H`): default is `24px × 24px` for menu icons. The user may request different dimensions (e.g., 36×36, 48×48, or non-square). Always check the request.
+2. **Content padding**: default is ~2px equivalent on each side at the output scale (so content fills roughly (OUT_W-4) × (OUT_H-4)). The user may request different padding or edge-to-edge.
+3. **Centering**: default is centered both horizontally and vertically. The user may request specific alignment (e.g., "align to bottom").
+
+#### Sub-step 2: Parse the raw SVG
+
+1. Extract the `viewBox`: `viewBox="VB_X VB_Y VB_W VB_H"` (typically `0 0 W H`).
+2. Identify ALL paths. Classify each:
+   - **Background**: a rect or path spanning the full viewBox (first path that's a simple rectangle matching the viewBox bounds). **Remove it entirely.**
+   - **Content**: the actual icon shapes. **Keep these, paths unchanged.**
+3. If paths have `transform="translate(TX,TY)"` attributes, that's fine — keep them as-is. The viewBox framing will work regardless.
+
+#### Sub-step 3: Compute the content bounding box
+
+Estimate the bounding box of the content paths (after removing the background). You can either:
+- Eyeball it from the path coordinates (look at first/last M commands and extremes of curves)
+- Or for precision, write a quick script to parse the paths and find min/max X/Y
+
+Call the result: `CX_MIN, CY_MIN, CX_MAX, CY_MAX`. Content dimensions: `CW = CX_MAX - CX_MIN`, `CH = CY_MAX - CY_MIN`.
+
+#### Sub-step 4: Compute the new viewBox
+
+The viewBox determines what part of the SVG coordinate space maps to the output rectangle. By expanding the viewBox beyond the content bounds, we add padding. By making the viewBox aspect ratio match the output aspect ratio, we prevent stretching.
+
+1. **Output aspect ratio**: `OUT_AR = OUT_W / OUT_H` (for 24×24 this is 1.0).
+2. **Padding in SVG coordinates**: we want ~2px padding at output scale. The scale factor is `OUT_W / VB_CONTENT_W` approximately, so padding in SVG coords = `2 * (CW / (OUT_W - 4))` (or similar — the exact formula depends on which dimension is dominant). Simpler approach: aim for content to occupy ~83% of the viewBox (≈ 20/24), so:
+   - `PADDED_W = CW / 0.83`
+   - `PADDED_H = CH / 0.83`
+3. **Match output aspect ratio**: the viewBox aspect ratio must equal `OUT_AR` to avoid stretching.
+   - If `PADDED_W / PADDED_H > OUT_AR`: width is dominant → `VB_W = PADDED_W`, `VB_H = VB_W / OUT_AR`
+   - If `PADDED_W / PADDED_H < OUT_AR`: height is dominant → `VB_H = PADDED_H`, `VB_W = VB_H * OUT_AR`
+   - If equal: `VB_W = PADDED_W`, `VB_H = PADDED_H`
+4. **Center the content** in the new viewBox:
+   - `VB_X = CX_MIN - (VB_W - CW) / 2`
+   - `VB_Y = CY_MIN - (VB_H - CH) / 2`
+   - (Adjust if the user requested non-centered alignment)
+
+The new viewBox is: `viewBox="VB_X VB_Y VB_W VB_H"`.
+
+#### Sub-step 5: Recolor to white-on-transparent
+
+- Replace ALL `fill` color values (anything that isn't `none`) with `#FFFFFF`.
+- Remove ALL `stroke` and `stroke-width` attributes entirely.
+- Remove `opacity` attributes if present.
+
+#### Sub-step 6: Determine path composition
+
+Look at the icon's visual structure and decide how paths should combine:
+- **Outlined shape** (e.g., circle outline with something inside): combine outer + inner cutout into one `<path>` with `fill-rule="evenodd"`.
+- **Separate distinct parts** (e.g., magnifying glass + checkmark): keep as separate `<path>` elements.
+- **Filled shape with cutout** (e.g., filled circle with checkmark punched out): combine into one path with `fill-rule="evenodd"`.
+
+#### Sub-step 7: Assemble final SVG
+
+```xml
+<?xml version="1.0" encoding="UTF-8"?>
+<svg width="{OUT_W}px" height="{OUT_H}px" viewBox="{VB_X} {VB_Y} {VB_W} {VB_H}" xmlns="http://www.w3.org/2000/svg">
+    <g stroke="none" fill="none" fill-rule="evenodd">
+        <path d="..." fill="#FFFFFF"></path>
+    </g>
+</svg>
+```
+
+- `width`/`height` = the output size from the request (default `24px`/`24px`).
+- `viewBox` = the computed viewBox from Sub-step 4. The SVG renderer maps this coordinate region to the output size.
+- Path `d` attributes are **unchanged** from vectosolve output (just background removed, colors replaced).
+- No `<title>`, `id`, `xmlns:xlink`, `version`, `class`, `style`, XML comments, `<metadata>`, or `preserveAspectRatio`.
+- No `<circle>`, `<rect>`, `<line>` — only `<path>`.
+
+Write the final SVG to `.ai/icon_{name}/{LETTER}.svg`.
+
+### Step 1c: Render
+
+If `RENDER_AVAILABLE`:
+```bash
+$CODEGEN --render-svg ".ai/icon_{name}/{LETTER}.svg" ".ai/icon_{name}/render_{LETTER}.png" 512
+```
+
+Read the render to visually verify the result.
+
+## Phase 2: Review
+
+After rendering, assess the result:
+
+1. **Recognizable?** The icon should be clearly identifiable as the intended symbol.
+2. **Scale reasonable?** Should fill the space appropriately with ~2-3px padding.
+3. **Clean lines?** No broken paths, artifacts, or unwanted elements.
+4. **Correct colors?** All white on transparent (no leftover colors from the mockup).
+
+If the result looks good → proceed to Phase 3 (Output).
+
+If there are fixable issues (stray element, missed color, etc.) → fix the SVG directly, re-render, and re-check.
+
+If the result is poor (vectosolve couldn't handle the input well) → report to the user and suggest:
+- Trying a cleaner/larger crop of the icon
+- Providing a different screenshot
+- Following up: `/icon {icon_name} <description of what to change>`
+
+## Phase 3: Output
+
+1. Read the `Target:` line from `.ai/icon_{name}/context.md` to get the output path.
+
+2. Copy the final SVG to that target path (e.g., `Telegram/Resources/icons/menu/{icon_name}.svg`).
+
+3. Update `.ai/icon_{name}/context.md` — append to the end:
+   ```
+   ## Latest Output
+   Letter: {LETTER}
+   Written to: {target_path}
+   ```
+
+4. Report to the user:
+   - Final icon file path
+   - Number of vectosolve calls made (cost at $0.20/call)
+   - Suggest verifying visually
+   - Working directory `.ai/icon_{name}/` has all iterations
+   - Elapsed time since `$START_TIME` (format `Xm Ys`)
+   - Follow-up: `/icon {icon_name} <description of what to change>`
+
+## Text-only Follow-ups (no new image)
+
+When a follow-up has no attached image, the user wants to refine the existing SVG based on text feedback. In this case:
+
+1. Skip Phase 1 (no vectosolve call needed).
+2. Read the latest SVG (`.ai/icon_{name}/{prev_letter}.svg`).
+3. Read the latest render if available.
+4. Apply the user's requested changes by editing the SVG directly.
+5. Save as `.ai/icon_{name}/{LETTER}.svg`.
+6. Render, review, and output as normal (Phases 1c → 3).
+
+If the changes are too complex for manual SVG editing, suggest the user provide a new screenshot instead.
+
+## Error Handling
+
+- If clipboard grab fails → tell user to re-copy and retry.
+- If vectosolve returns an error → report it and suggest a different/cleaner screenshot.
+- If vectosolve returns SVG that can't be parsed → save raw output for debugging, report to user.
+- If the render helper fails → set `RENDER_AVAILABLE = false`, continue with SVG-only review.
+- If post-processing produces a broken SVG → fall back to the raw vectosolve output and do lighter cleanup.
@@ -0,0 +1,122 @@
+---
+description: Plan and create a repetitive task automation (prompt.md + tasks.json pair)
+allowed-tools: Read, Write, Edit, Glob, Grep, Bash(mkdir:*), Bash(ls:*), AskUserQuestion
+---
+
+# Task Planner - Create Automated Task Workflows
+
+You are setting up a new **repetitive task automation** for Claude Code. The goal is to create a folder in `.ai/<featurename>/` containing:
+- `prompt.md` - Detailed instructions for the autonomous agent
+- `tasks.json` - List of tasks with completion tracking
+
+This pair can then be executed via `.claude/iterate.ps1 <featurename>`.
+
+## Your Workflow
+
+### 1. Understand the Goal
+
+First, understand what the user wants to automate. Ask clarifying questions using AskUserQuestion if needed:
+- What is the overall goal/feature being implemented?
+- What are the individual tasks involved?
+- Are there dependencies between tasks?
+- What files/areas of the codebase are involved?
+- Are there any reference examples or patterns to follow?
+
+### 2. Choose a Feature Name
+
+The `<featurename>` should be:
+- Short (1-2 words, lowercase, hyphen-separated)
+- Easy to type on command line
+- Descriptive of the work being done
+- Not already used in `.ai/`
+
+Check existing folders:
+```bash
+ls .ai/
+```
+
+Suggest a name to the user or let them specify one directly via $ARGUMENTS.
+
+
+### 3. Create the Folder and Files
+
+Create `.ai/<featurename>/`:
+
+**prompt.md** should include:
+- Overview of what we're doing
+- Architecture/context needed
+- Step-by-step instructions for each task type
+- Code patterns and examples
+- Build/test commands
+- Commit message format (see below)
+
+### Commit Message Guidelines
+
+All prompts should specify commit message length requirements:
+- **Soft limit**: ~50 characters (ideal length for first line)
+- **Hard limit**: 76 characters (must not exceed)
+
+Example instruction for prompt.md:
+```
+## Commit Format
+
+First line: Short summary ending with a dot (aim for ~50 chars, max 76 chars)
+
+<Optional body with details, also ending with a dot.>
+
+IMPORTANT: Never try to commit files in .ai/
+```
+
+**tasks.json** format:
+```json
+{
+  "tasks": [
+    {
+      "id": "task-id",
+      "title": "Short task title",
+      "description": "Detailed description of what to do",
+      "started": false,
+      "completed": false,
+      "dependencies": ["other-task-id"]
+    }
+  ]
+}
+```
+
+### 4. Iterate with the User
+
+After creating initial files, the user may want to:
+- Add more tasks to tasks.json
+- Refine the prompt with more details
+- Add examples or patterns
+- Clarify instructions
+
+Keep refining until the user is satisfied.
+
+## Arguments
+
+If `$ARGUMENTS` is provided, it's the feature name to use:
+- `$ARGUMENTS` = "$ARGUMENTS"
+
+If empty, you'll need to determine/suggest a name based on the discussion.
+
+## Examples
+
+### Example 1: Settings Migration
+```
+/taskplanner settings-upgrade
+```
+Creates `.ai/settings-upgrade/` with prompt and tasks for migrating settings sections.
+
+### Example 2: Open-ended
+```
+/taskplanner
+```
+Starts a conversation to understand what needs to be automated, then creates the appropriate folder.
+
+## Starting Point
+
+Let's begin! Please describe:
+1. What repetitive coding task do you want to automate?
+2. What is the end goal?
+3. Do you have initial tasks in mind, or should we discover them together?
@@ -0,0 +1,136 @@
+---
+description: Learn from corrections — examine staged vs unstaged diffs and optionally distill insights into AGENTS.md or REVIEW.md
+allowed-tools: Read, Edit, Bash(git diff:*), Bash(git status:*), Bash(git log:*), Bash(ls:*), AskUserQuestion
+---
+
+# Reflect — Learn from Corrections
+
+You are a reflection agent. Your job is to examine the difference between what an AI agent produced (staged changes) and what the user corrected (unstaged changes), and determine whether any **general, reusable insight** can be extracted and added to the project's coding guidelines.
+
+**CRITICAL: Use extended thinking ultrathink for your analysis. This requires deep, careful reasoning.**
+
+## Arguments
+
+`$ARGUMENTS` = "$ARGUMENTS"
+
+If `$ARGUMENTS` is provided, it is a task name (project name from the `/task` workflow). This means the agent was working within `.ai/<task-name>/` and you should read the task context for deeper understanding of what the agent was trying to do.
+
+If `$ARGUMENTS` is empty, skip the task context step — just work from the diffs alone.
+
+## Context
+
+The workflow is:
+1. An AI agent implemented something and its changes were staged (`git add`).
+2. The user reviewed and corrected the agent's work. These corrections are unstaged.
+3. You are now invoked to reflect on what went wrong and whether it reveals a pattern.
+
+## Step 1: Gather the Diffs and Task Context
+
+Run these commands in parallel:
+
+```bash
+git diff --cached    # What the agent wrote (staged)
+git diff             # What the user corrected (unstaged, on top of staged)
+git status           # Which files are involved
+```
+
+If either diff is empty, tell the user and stop. Both diffs must be non-empty for reflection to be meaningful.
+
+### Task context (only if `$ARGUMENTS` is non-empty)
+
+The task name is `$ARGUMENTS`. Read the task's project context:
+
+1. Read `.ai/$ARGUMENTS/about.md` — the project-level description of what this feature does.
+2. Find the latest task iteration folder: list `.ai/$ARGUMENTS/` and pick the folder with the highest letter (`a`, `b`, `c`, ...).
+3. Read `.ai/$ARGUMENTS/<latest-letter>/context.md` — the detailed implementation context the agent was working from.
+
+This helps you distinguish between:
+- **Task-specific mistakes** — the agent misunderstood this particular feature's requirements or made a wrong choice within the specific problem. These are NOT documentation-worthy.
+- **General convention mistakes** — the agent did something that violates a pattern the codebase follows broadly, regardless of which feature is being implemented. These ARE potentially documentation-worthy.
+
+Having the task context makes this distinction much sharper. Without it, you might mistake a task-specific correction for a general pattern or vice versa.
+
+## Step 2: Read the Current Guidelines
+
+Read both files:
+- `AGENTS.md` — development guidelines: build system, coding style, API usage patterns, UI styling, localization, rpl, architectural conventions, "how to do things"
+- `REVIEW.md` — mechanical style and formatting rules: brace placement, operator position, type checks, variable initialization, call formatting
+
+Read them carefully. You need to know exactly what's already documented to avoid duplicates and detect contradictions.
+
+## Step 3: Analyze the Corrections
+
+Now think deeply. For each correction the user made, ask yourself:
+
+1. **What did the agent do wrong?** Understand the specific mistake.
+2. **Why was it wrong?** Identify the underlying principle.
+3. **Is this already covered by AGENTS.md or REVIEW.md?** Check carefully:
+   - If the existing rule's scope, title, and examples **clearly cover** this exact scenario and the agent just ignored it — that's not a documentation problem. Skip it.
+   - If the existing rule **technically applies** but its scope is too narrow, its examples don't illustrate this usage pattern, or its wording would reasonably lead an agent to think it doesn't apply here — **the rule needs improvement**. Treat this as a potential insight (broaden the scope, add examples, adjust wording). A rule that agents repeatedly violate is an ineffective rule.
+4. **Is this specific to this particular task, or is it general?** Most corrections are task-specific ("wrong variable here", "this should call that function instead"). These are NOT documentation-worthy. Only patterns that would apply across many different tasks are worth capturing.
+5. **Would documenting this actually help a future agent?** Some things are too context-dependent or too obvious to be useful as a written rule. Be honest about this.
+
+## Step 4: Decision
+
+After analysis, you MUST reach one of these conclusions:
+
+### Conclusion A: No actionable insight
+
+The corrections are purely task-specific, or the existing documentation clearly and specifically covers the exact scenario and the agent simply ignored it. Say what the corrections were and why no doc changes are needed. Then **stop**.
+
+### Conclusion B: New insight found
+
+You can articulate a **concise, general rule** that:
+- Applies broadly (not just to this one task)
+- Is not already documented
+- Would genuinely help a future agent avoid the same class of mistake
+- Can be expressed in a few sentences with a clear code example
+
+If you have a new insight, proceed to Step 5.
+
+### Conclusion C: Existing rule needs improvement
+
+A rule already exists in AGENTS.md or REVIEW.md, but its **scope is too narrow**, its **examples don't cover** the pattern the agent encountered, or its **wording** would reasonably lead an agent to think the rule doesn't apply. The agent's mistake is evidence the rule isn't effective.
+
+This is NOT the same as Conclusion A. The test: would a careful agent, reading the existing rule, clearly know it applies to this specific situation? If no — the rule needs to be broadened, its examples expanded, or its title/scope adjusted. Proceed to Step 5.
+
+**Common signs of an ineffective rule:**
+- The rule's title or scope restricts it to a context narrower than the actual principle (e.g., "in localization calls" when the pattern applies generally)
+- The examples only show one usage pattern, and the agent encountered a different one
+- The wording describes *what* to use but not *when* — so agents only apply it in situations that look like the examples
+
+## Step 5: Categorize and Check for Contradictions
+
+### Where does it belong?
+
+- **REVIEW.md** — if it's a mechanical/style rule: formatting, naming, syntax preferences, call structure, brace/operator placement, type usage patterns. Rules that can be checked by looking at code locally without understanding the broader feature.
+- **AGENTS.md** — if it's an architectural/behavioral guideline: how to use APIs, where to place code, design patterns, build conventions, module organization, reactive patterns (rpl), localization usage, style system usage. Rules that require understanding the broader context.
+
+### Does it contradict existing content?
+
+Read the target file again carefully. Check if:
+1. The new insight **contradicts** an existing rule — if so, do NOT just append or just remove. Instead, use AskUserQuestion to present both the existing rule and the new insight to the user, explain the contradiction, and ask how to reconcile them.
+2. The new insight **overlaps** with an existing rule — if so, consider whether the existing rule should be extended/refined rather than adding a separate entry.
+3. The new insight is **complementary** — it adds something new without conflicting. This is the simplest case.
+
+## Step 6: Propose the Change
+
+**Do NOT silently edit the files.** First, present your proposed change to the user:
+
+- Quote the exact text you want to add or modify
+- Explain which file and where in the file
+- Explain why this is general enough to document
+- If modifying existing text, show the before and after
+
+Use AskUserQuestion to get the user's approval before making any edit.
+
+Only after the user approves, apply the edit using the Edit tool.
+
+## Rules
+
+- **Keep docs lean and high-signal.** Don't add vague or overly specific rules. But don't default to inaction either — if the user had to manually fix something that a better-worded rule would have prevented, improving that rule is high-signal work.
+- **Never dump corrections verbatim.** The goal is distilled principles, not a changelog of mistakes.
+- **One insight per reflection, maximum.** If you think you see multiple insights, pick the strongest one. You can always run `/reflect` again next time.
+- **Keep the same style.** Match the formatting, tone, and level of detail of the target file. REVIEW.md uses specific before/after code examples. AGENTS.md uses explanatory sections with code snippets.
+- **Don't add "don't do X" rules.** Frame rules positively: "do Y" is better than "don't do X." Show the right way, not just the wrong way.
+- **No meta-commentary.** Don't add notes like "Added after reflection on..." — the rule should read as if it was always there.
@@ -0,0 +1,119 @@
+---
+description: Prepare changelog, set version, and commit a new release
+allowed-tools: Read, Bash, Edit, Grep, AskUserQuestion
+---
+
+# Release — Changelog, Set Version, Commit
+
+Full release flow: generate changelog entry, run `set_version`, and commit.
+
+**Arguments:** `$ARGUMENTS` = "$ARGUMENTS"
+
+Parse `$ARGUMENTS` for two optional parts (in any order):
+- A **version number** like `6.7` or `6.7.0` — if provided, use it as the new version exactly.
+- The word **"beta"** — if present, mark the release as beta.
+
+If no version number is given, auto-increment the patch component (see step 2).
+
+## Steps
+
+### 1. Check git status is clean
+
+Run `git status --porcelain`. If there are any uncommitted changes, **stop** and ask the user to commit or discard them before proceeding. Do not continue until status is clean.
+
+### 2. Read the current changelog
+
+Read `changelog.txt` from the repository root. Note the **latest version number** on the first line (e.g. `6.6.3 beta (12.03.26)`). Parse its major.minor.patch components.
+
+### 3. Determine the new version number
+
+**Important:** version numbers are shared across the beta and stable tracks — the sequence advances through both. The same `major.minor.patch` cannot be released as both beta and stable. A beta release "uses up" that number; the next stable must bump to a new patch.
+
+- **If a version was provided in arguments**, use it directly (append `.0` if only major.minor was given). If the latest changelog entry already used this exact number (regardless of beta/stable), warn the user — they likely want a bumped patch.
+- **If no version was provided**, auto-increment from the latest changelog version:
+  - If it was a beta, and the new release is **not** beta, bump the patch component by 1 (do **not** reuse the beta's number for stable).
+  - If the new release is beta and the latest was also beta with the same major.minor, bump patch.
+  - Otherwise bump the patch component by 1.
+- Present the chosen version to the user and ask for confirmation before proceeding. If the user suggests a different version, use that instead.
+
+### 4. Fetch tags and determine the last release tag
+
+Run `git fetch origin --tags` first to ensure all tags from the public repository are available locally. Then run `git tag --sort=-v:refname` and find the most recent `v*` tag. This is the baseline for the diff.
+
+### 5. Collect commits
+
+Run `git log <last-tag>..HEAD --oneline` to get all commits since the last release.
+
+### 6. Write the changelog entry
+
+Analyze every commit message. Group them mentally into features, improvements, and bug fixes. Then produce **brief, user-facing bullet points** following these rules:
+
+- **Style:** Match the existing changelog tone exactly — short, imperative sentences starting with a verb (Fix, Add, Allow, Show, Improve, Support…). Keep the trailing periods (the existing changelog uses them).
+- **Brevity:** Each bullet should be one short sentence, around 80 characters when possible. No implementation details. No commit hashes.
+- **Selection:** Only include changes that matter to end users. Skip CI, build infra, submodule bumps, code style, refactors, and intermediate WIP commits. Collapse many related commits (e.g. a dozen image-editor commits) into one or two bullets.
+- **Ordering:** Features first, then improvements, then bug fixes.
+- **Quantity:** Aim for 4-12 bullets total depending on the amount of changes.
+
+### 7. Format and insert into changelog.txt
+
+Use this exact format (date is today in DD.MM.YY):
+
+```
+<version> [beta ](DD.MM.YY)
+
+- Bullet one.
+- Bullet two.
+```
+
+Prepend the new entry at the very top of `changelog.txt`, separated by a blank line from the previous first entry. Use the Edit tool.
+
+**Never delete or edit existing entries**, even if the new stable entry merges bullets from prior beta(s). Prior beta blocks remain as historical record for beta-track users.
+
+**For stable releases spanning prior beta(s):** the entry should cover everything since the last **stable** release (not just since the last beta), including noteworthy beta-shipped features, trimmed as needed to stay within 4–12 bullets.
+
+### 8. Wait for approval
+
+After writing the entry to `changelog.txt` (step 7), tell the user the changelog has been updated and ask them to review it in the IDE. They can edit it directly and tell you to continue, or tell you what to change in chat. Do **not** print the full entry in chat — the file itself is the review surface.
+
+**Do NOT proceed until the user explicitly approves.**
+
+### 9. Run set_version
+
+Once approved, run the `set_version` script from the repository root. On Windows:
+
+```
+.\Telegram\build\set_version.bat <version_arg>
+```
+
+Where `<version_arg>` is formatted as the `set_version` script expects:
+- Stable: `6.7.0` or `6.7`
+- Beta: `6.7.0.beta`
+
+Verify the script exits successfully (exit code 0). If it fails, show the error and stop.
+
+### 10. Commit
+
+Stage all changes and create a commit. The commit message format:
+
+**First line:**
+- For stable: `Version <major>.<minor>.` if patch is 0, otherwise `Version <major>.<minor>.<patch>.`
+- For beta: `Beta version <major>.<minor>.<patch>.`
+
+**Then an empty line, then the changelog bullets.** Copy bullet lines from the changelog as-is. Only wrap lines that exceed 72 characters; shorter lines must stay on a single line. When wrapping is needed, break at logically correct places (between words/phrases) and indent continuation lines with two spaces.
+
+Example commit message:
+```
+Beta version 6.6.3.
+
+- Drawing tools in image editor
+  (brush, marker, eraser, arrow).
+- Draw-to-reply button in media viewer.
+- Trim recorded voice messages.
+- Fix reorder freeze in chats list.
+```
+
+Use a HEREDOC to pass the message to `git commit -a`.
+
+### 11. Done
+
+Run `git log -1` to show the resulting commit and confirm success.
@@ -0,0 +1,506 @@
+---
+description: Implement a feature or fix using multi-agent workflow with fresh context at each phase
+allowed-tools: Read, Write, Edit, Glob, Grep, Bash, Task, AskUserQuestion, TodoWrite
+---
+
+# Task - Multi-Agent Implementation Workflow
+
+You orchestrate a multi-phase implementation workflow that uses fresh agent spawns to work within context window limits on a large codebase.
+
+**Arguments:** `$ARGUMENTS` = "$ARGUMENTS"
+
+If `$ARGUMENTS` is provided, it's the task description. If empty, ask the user what they want implemented.
+
+## Overview
+
+The workflow is organized around **projects**. Each project lives in `.ai/<project-name>/` and can contain multiple sequential **tasks** (labeled `a`, `b`, `c`, ... `z`).
+
+Project structure:
+```
+.ai/<project-name>/
+  about.md              # Single source of truth for the entire project
+  a/                    # First task
+    context.md          # Gathered codebase context for this task
+    plan.md             # Implementation plan
+    review1.md          # Code review documents (up to 3)
+    review2.md
+    review3.md
+  b/                    # Follow-up task
+    context.md
+    plan.md
+    review1.md
+  c/                    # Another follow-up task
+    ...
+```
+
+- `about.md` is the project-level blueprint — a single comprehensive document describing what this project does and how it works, written as if everything is already fully implemented. It contains no temporal state ("current state", "pending changes", "not yet implemented"). It is **rewritten** (not appended to) each time a new task starts, incorporating the new task's changes as if they were always part of the design.
+- Each task folder (`a/`, `b/`, ...) contains self-contained files for that task. The task's `context.md` carries all task-specific information: what specifically needs to change, the delta from the current codebase, gathered file references and code patterns. Planning, implementation, and review agents only read the current task's folder.
+
+## Phase 0: Setup
+
+**Record the current time now** (using `Get-Date` in PowerShell or equivalent) and store it as `$START_TIME`. You will use this at the end to display total elapsed time.
+
+⚠️ **CRITICAL: Follow-up detection MUST happen FIRST, before anything else.**
+
+### Step 0a: Follow-up detection (MANDATORY — do this BEFORE understanding the task)
+
+Extract the first word/token from `$ARGUMENTS` (everything before the first space or newline). Call it `FIRST_TOKEN`.
+
+Then run these TWO commands using the Bash tool, IN PARALLEL, right now:
+1. `ls .ai/` — to see all existing project names
+2. `ls .ai/<FIRST_TOKEN>/about.md` — to check if this specific project exists
+
+**Evaluate the results:**
+- If command 2 **succeeds** (the file exists): this is a **follow-up task**. The project name is `FIRST_TOKEN`. The task description is everything in `$ARGUMENTS` AFTER `FIRST_TOKEN` (strip leading whitespace).
+- If command 2 **fails** (file not found): this is a **new project**. The full `$ARGUMENTS` is the task description.
+
+**Do NOT proceed to step 0b until you have run these commands and determined follow-up vs new.**
+
+### Step 0b: Project setup
+
+**For new projects:**
+- Using the list from command 1, pick a unique short name (1-2 lowercase words, hyphen-separated) that doesn't collide with existing projects.
+- Create `.ai/<project-name>/` and `.ai/<project-name>/a/`.
+- Set current task letter = `a`.
+
+**For follow-up tasks:**
+- Scan `.ai/<project-name>/` for existing task folders (`a/`, `b/`, ...). Find the latest one (highest letter).
+- The previous task letter = that highest letter.
+- The new task letter = next letter in sequence.
+- Create `.ai/<project-name>/<new-letter>/`.
+
+Then proceed to Phase 1 (Context Gathering) in both cases. Follow-up tasks do NOT skip context gathering — they go through a modified version of it.
+
+## Phase 1: Context Gathering
+
+### For New Projects (task letter = `a`)
+
+Spawn an agent (Task tool, subagent_type=`general-purpose`) with this prompt structure:
+
+```
+You are a context-gathering agent for a large C++ codebase (Telegram Desktop).
+
+TASK: <paste the user's task description here>
+
+YOUR JOB: Read AGENTS.md, inspect the codebase, find ALL files and code relevant to this task, and write two documents.
+
+Steps:
+1. Read AGENTS.md for project conventions and build instructions.
+2. Search the codebase for files, classes, functions, and patterns related to the task.
+3. Read all potentially relevant files. Be thorough - read more rather than less.
+4. For each relevant file, note:
+   - File path
+   - Relevant line ranges
+   - What the code does and how it relates to the task
+   - Key data structures, function signatures, patterns used
+5. Look for similar existing features that could serve as a reference implementation.
+6. Check api.tl if the task involves Telegram API.
+7. Check .style files if the task involves UI.
+8. Check lang.strings if the task involves user-visible text.
+
+Write TWO files:
+
+### File 1: .ai/<project-name>/about.md
+
+NOTE: This file is NOT used by any agent in the current task. It exists solely as a starting point for a FUTURE follow-up task's context gatherer. No planning, implementation, or review agent will ever read it. Only the context-gathering agent of the next follow-up task reads about.md (together with the latest context.md) to produce a fresh context.md for that next task.
+
+Write it as if the project is already fully implemented and working. It should contain:
+- **Project**: What this project does (feature description, goals, scope)
+- **Architecture**: High-level architectural decisions, which modules are involved, how they interact
+- **Key Design Decisions**: Important choices made about the approach
+- **Relevant Codebase Areas**: Which parts of the codebase this project touches, key types and APIs involved
+
+Do NOT include temporal state like "Current State", "Pending Changes", "Not yet implemented", "TODO", or any other framing that distinguishes between "done" and "not done". Describe the project as a complete, coherent whole — as if everything is already working. This is a project overview, not a status tracker. Task-specific work belongs exclusively in context.md.
+
+### File 2: .ai/<project-name>/a/context.md
+
+This is the task-specific implementation context. This is the PRIMARY document — all downstream agents (planning, implementation, review) will read ONLY this file. It must be completely self-contained. It should contain:
+- **Task Description**: The full task restated clearly
+- **Relevant Files**: Every file path with line ranges and descriptions of what's there
+- **Key Code Patterns**: How similar things are done in the codebase (with code snippets)
+- **Data Structures**: Relevant types, structs, classes
+- **API Methods**: Any TL schema methods involved (copied from api.tl)
+- **UI Styles**: Any relevant style definitions
+- **Localization**: Any relevant string keys
+- **Build Info**: Build command and any special notes
+- **Reference Implementations**: Similar features that can serve as templates
+
+Be extremely thorough. Another agent with NO prior context will read this file and must be able to understand everything needed to implement the task.
+```
+
+After this agent completes, read both `about.md` and `a/context.md` to verify they were written properly.
+
+### For Follow-up Tasks (task letter = `b`, `c`, ...)
+
+Spawn an agent (Task tool, subagent_type=`general-purpose`) with this prompt structure:
+
+```
+You are a context-gathering agent for a follow-up task on an existing project in a large C++ codebase (Telegram Desktop).
+
+NEW TASK: <paste the follow-up task description here>
+
+YOUR JOB: Read the existing project state, gather any additional context needed, and produce fresh documents for the new task.
+
+Steps:
+1. Read AGENTS.md for project conventions and build instructions.
+2. Read .ai/<project-name>/about.md — this is the project-level blueprint describing everything done so far.
+3. Read .ai/<project-name>/<previous-letter>/context.md — this is the previous task's gathered context.
+4. Understand what has already been implemented by reading the actual source files referenced in about.md and the previous context.
+5. Based on the NEW TASK description, search the codebase for any ADDITIONAL files, classes, functions, and patterns that are relevant to the new task but not already covered.
+6. Read all newly relevant files thoroughly.
+
+Write TWO files:
+
+### File 1: .ai/<project-name>/about.md (REWRITE)
+
+NOTE: This file is NOT used by any agent in the current task. It exists solely as a starting point for a FUTURE follow-up task's context gatherer. No planning, implementation, or review agent will ever read it. You are rewriting it now so that the next follow-up has an accurate project overview to start from.
+
+REWRITE this file (not append). The new about.md must be a single coherent document that describes the project as if everything — including this new task's changes — is already fully implemented and working.
+
+It should incorporate:
+- Everything from the old about.md that is still accurate and relevant
+- The new task's functionality described as part of the project (not as "changes to make")
+- Any changed design decisions or architectural updates from the new task requirements
+
+It should NOT contain:
+- Any temporal state: "Current State", "Pending Changes", "TODO", "Not yet implemented"
+- History of how requirements changed between tasks
+- References to "the old approach" vs "the new approach"
+- Task-by-task changelog or timeline
+- Any distinction between "what was done before" and "what this task adds"
+- Information that contradicts the new task requirements (if the new task changes direction, the about.md should reflect the NEW direction as if it was always the plan)
+
+Think of about.md as "the complete description of what this project does and how it works." Someone reading it should understand the full project as a finished product, without knowing it went through multiple tasks.
+
+### File 2: .ai/<project-name>/<new-letter>/context.md
+
+This is the PRIMARY document — all downstream agents (planning, implementation, review) will read ONLY this file. It must be completely self-contained. about.md will NOT be available to them.
+
+It should contain:
+- **Task Description**: The new task restated clearly, with enough project background (from about.md and previous context.md) that an implementation agent can understand it without reading any other .ai/ files
+- **Relevant Files**: Every file path with line ranges relevant to THIS task (including files modified by previous tasks and any newly relevant files)
+- **Key Code Patterns**: How similar things are done in the codebase
+- **Data Structures**: Relevant types, structs, classes
+- **API Methods**: Any TL schema methods involved
+- **UI Styles**: Any relevant style definitions
+- **Localization**: Any relevant string keys
+- **Build Info**: Build command and any special notes
+- **Reference Implementations**: Similar features that can serve as templates
+
+Be extremely thorough. Another agent with NO prior context will read ONLY this file and must be able to understand everything needed to implement the new task. Do NOT assume the reader has seen about.md or any previous task files. The context.md is the single source of truth for all downstream agents — it must include all relevant project background, not just the delta.
+```
+
+After this agent completes, read both `about.md` and `<new-letter>/context.md` to verify they were written properly.
+
+## Phase 2: Planning
+
+Spawn an agent (Task tool, subagent_type=`general-purpose`) with this prompt structure:
+
+```
+You are a planning agent. You must create a detailed implementation plan.
+
+Read these files:
+- .ai/<project-name>/<letter>/context.md - Contains all gathered context for this task
+- Then read the specific source files referenced in context.md to understand the code deeply.
+
+Think carefully about the implementation approach.
+
+Create a detailed plan in: .ai/<project-name>/<letter>/plan.md
+
+The plan.md should contain:
+
+## Task
+<one-line summary>
+
+## Approach
+<high-level description of the implementation approach>
+
+## Files to Modify
+<list of files that will be created or modified>
+
+## Files to Create
+<list of new files, if any>
+
+## Implementation Steps
+
+Each step must be specific enough that an agent can execute it without ambiguity:
+- Exact file paths
+- Exact function names
+- What code to add/modify/remove
+- Where exactly in the file (after which function, in which class, etc.)
+
+Number every step. Group steps into phases if there are more than ~8 steps.
+
+### Phase 1: <name>
+1. <specific step>
+2. <specific step>
+...
+
+### Phase 2: <name> (if needed)
+...
+
+## Build Verification
+- Build command to run
+- Expected outcome
+
+## Status
+- [ ] Phase 1: <name>
+- [ ] Phase 2: <name> (if applicable)
+- [ ] Build verification
+- [ ] Code review
+```
+
+After this agent completes, read `plan.md` to verify it was written properly.
+
+## Phase 3: Plan Assessment
+
+Spawn an agent (Task tool, subagent_type=`general-purpose`) with this prompt structure:
+
+```
+You are a plan assessment agent. Review and refine an implementation plan.
+
+Read these files:
+- .ai/<project-name>/<letter>/context.md
+- .ai/<project-name>/<letter>/plan.md
+- Then read the actual source files referenced to verify the plan makes sense.
+
+Carefully assess the plan:
+
+1. **Correctness**: Are the file paths and line references accurate? Does the plan reference real functions and types?
+2. **Completeness**: Are there missing steps? Edge cases not handled?
+3. **Code quality**: Will the plan minimize code duplication? Does it follow existing codebase patterns from AGENTS.md?
+4. **Design**: Could the approach be improved? Are there better patterns already used in the codebase?
+5. **Phase sizing**: Each phase should be implementable by a single agent in one session. If a phase has more than ~8-10 substantive code changes, split it further.
+
+Update plan.md with your refinements. Keep the same structure but:
+- Fix any inaccuracies
+- Add missing steps
+- Improve the approach if you found better patterns
+- Ensure phases are properly sized for single-agent execution
+- Add a line at the top of the Status section: `Phases: <N>` indicating how many implementation phases there are
+- Add `Assessed: yes` at the bottom of the file
+
+If the plan is small enough for a single agent (roughly <=8 steps), mark it as a single phase.
+```
+
+After this agent completes, read `plan.md` to verify it was assessed.
+
+## Phase 4: Implementation
+
+Now read `plan.md` yourself to understand the phases.
+
+For each phase in the plan that is not yet marked as done, spawn an implementation agent (Task tool, subagent_type=`general-purpose`):
+
+```
+You are an implementation agent working on phase <N> of an implementation plan.
+
+Read these files first:
+- .ai/<project-name>/<letter>/context.md - Full codebase context
+- .ai/<project-name>/<letter>/plan.md - Implementation plan
+
+Then read the source files you'll be modifying.
+
+YOUR TASK: Implement ONLY Phase <N> from the plan:
+<paste the specific phase steps here>
+
+Rules:
+- Follow the plan precisely
+- Follow AGENTS.md coding conventions (no comments except complex algorithms, use auto, empty line before closing brace, etc.)
+- Do NOT modify .ai/ files except to update the Status section in plan.md
+- When done, update plan.md Status section: change `- [ ] Phase <N>: ...` to `- [x] Phase <N>: ...`
+- Do NOT work on other phases
+
+When finished, report what you did and any issues encountered.
+```
+
+After each implementation agent returns:
+1. Read `plan.md` to check the status was updated.
+2. If more phases remain, spawn the next implementation agent.
+3. If all phases are done, proceed to build verification.
+
+## Phase 5: Build Verification
+
+Only run this phase if the task involved modifying project source code (not just docs or config).
+
+Spawn a build verification agent (Task tool, subagent_type=`general-purpose`):
+
+```
+You are a build verification agent.
+
+Read these files:
+- .ai/<project-name>/<letter>/context.md
+- .ai/<project-name>/<letter>/plan.md
+
+The implementation is complete. Your job is to build the project and fix any build errors.
+
+Steps:
+1. Run (from repository root): cmake --build ./out --config Debug --target Telegram
+2. If the build succeeds, update plan.md: change `- [ ] Build verification` to `- [x] Build verification`
+3. If the build fails:
+   a. Read the error messages carefully
+   b. Read the relevant source files
+   c. Fix the errors in accordance with the plan and AGENTS.md conventions
+   d. Rebuild and repeat until the build passes
+   e. Update plan.md status when done
+
+Rules:
+- Only fix build errors, do not refactor or improve code
+- Follow AGENTS.md conventions
+- If build fails with file-locked errors (C1041, LNK1104), STOP and report - do not retry
+
+When finished, report the build result.
+```
+
+After the build agent returns, read `plan.md` to confirm the final status. Then proceed to Phase 6.
+
+## Phase 6: Code Review Loop
+
+After build verification passes, run up to 3 review-fix iterations to improve code quality. Set iteration counter `R = 1`.
+
+### Review Loop
+
+```
+LOOP:
+  1. Spawn review agent (Step 6a) with iteration R
+  2. Read review<R>.md verdict:
+     - "APPROVED" → go to FINISH
+     - Has improvement suggestions → spawn fix agent (Step 6b)
+  3. After fix agent completes and build passes:
+     R = R + 1
+     If R > 3 → go to FINISH (stop iterating, accept current state)
+     Otherwise → go to step 1
+
+FINISH:
+  - Update plan.md: change `- [ ] Code review` to `- [x] Code review`
+  - Proceed to Completion
+```
+
+### Step 6a: Code Review Agent
+
+Spawn an agent (Task tool, subagent_type=`general-purpose`):
+
+```
+You are a code review agent for Telegram Desktop (C++ / Qt).
+
+Read these files:
+- .ai/<project-name>/<letter>/context.md - Codebase context
+- .ai/<project-name>/<letter>/plan.md - Implementation plan
+- REVIEW.md - Style and formatting rules to enforce
+<if R > 1, also read:>
+- .ai/<project-name>/<letter>/review<R-1>.md - Previous review (to see what was already addressed)
+
+Then run `git diff` to see all uncommitted changes made by the implementation. Implementation agents do not commit, so `git diff` shows exactly the current feature's changes.
+
+Then read the modified source files in full to understand changes in context.
+
+Perform a thorough code review.
+
+REVIEW CRITERIA (in order of importance):
+
+1. **Correctness and safety**: Obvious logic errors, missing null checks at API boundaries, potential crashes, use-after-free, dangling references, race conditions. This is the highest priority — bugs and safety issues must be caught first. Do NOT nitpick internal code that relies on framework guarantees.
+
+2. **Dead code**: Any code added or left behind that is never called or used, within the scope of the changes. Unused variables, unreachable branches, leftover scaffolding.
+
+3. **Redundant changes**: Changes in the diff that have no functional effect — moving declarations or code blocks to a different location without reason, reformatting untouched code, reordering includes or fields with no purpose. Every line in the diff should serve the feature. If a file appears in `git diff` but contains only no-op rearrangements, flag it for revert.
+
+4. **Code duplication**: Unnecessary repetition of logic that should be shared. Look for near-identical blocks that differ only in minor details and could be unified.
+
+5. **Wrong placement**: Code added to a module where it doesn't logically belong. If another existing module is a clearly better fit for the new code, flag it. Consider the existing module boundaries and responsibilities visible in context.md.
+
+6. **Function decomposition**: For longer functions (roughly 50+ lines), consider whether a logical sub-task could be cleanly extracted into a separate function. This is NOT a hard rule — a 100-line function that flows naturally and isn't easily divisible is perfectly fine. But sometimes even a 20-line function contains a clear isolated subtask that reads better as two 10-line functions. The key is to think about it each time: does extracting improve readability and reduce cognitive load, or does it just scatter logic across call sites for no real benefit? Only suggest extraction when there's a genuinely self-contained piece of logic with a clear name and purpose.
+
+7. **Module structure**: Only in exceptional cases — if a large amount of newly added code (hundreds of lines) is logically distinct from the rest of its host module, suggest extracting it into a new module. But do NOT suggest new modules lightly: every module adds significant build overhead due to PCH and heavy template usage. Only suggest this when the new code is both large enough AND logically separated enough to justify it. At the same time, don't let modules grow into multi-thousand-line monoliths either.
+
+8. **Style compliance**: Verify adherence to REVIEW.md rules (empty line before closing brace, operators at start of continuation lines, minimize type checks with direct cast instead of is+as, no if-with-initializer when simpler alternatives exist) and AGENTS.md conventions (no unnecessary comments, `auto` usage, no hardcoded sizes — must use .style definitions), etc.
+
+IMPORTANT GUIDELINES:
+- Review ONLY the changes made, not pre-existing code in the repository.
+- Be pragmatic. Don't suggest changes for the sake of it. Each suggestion should have a clear, concrete benefit.
+- Don't suggest adding comments, docstrings, or type annotations — the codebase style avoids these.
+- Don't suggest error handling for impossible scenarios or over-engineering.
+
+Write your review to: .ai/<project-name>/<letter>/review<R>.md
+
+The review document should contain:
+
+## Code Review - Iteration <R>
+
+## Summary
+<1-2 sentence overall assessment>
+
+## Verdict: <APPROVED or NEEDS_CHANGES>
+
+<If APPROVED, stop here. Everything looks good.>
+
+<If NEEDS_CHANGES, continue with:>
+
+## Changes Required
+
+### <Issue 1 title>
+- **Category**: <dead code | duplication | wrong placement | function decomposition | module structure | style | correctness>
+- **File(s)**: <file paths>
+- **Problem**: <clear description of what's wrong>
+- **Fix**: <specific description of what to change>
+
+### <Issue 2 title>
+...
+
+Keep the list focused. Only include issues that genuinely improve the code. If you find yourself listing more than ~5-6 issues, prioritize the most impactful ones.
+
+When finished, report your verdict clearly as: APPROVED or NEEDS_CHANGES.
+```
+
+After the review agent returns, read `review<R>.md`. If the verdict is APPROVED, proceed to Completion. If NEEDS_CHANGES, spawn the fix agent.
+
+### Step 6b: Review Fix Agent
+
+Spawn an agent (Task tool, subagent_type=`general-purpose`):
+
+```
+You are a review fix agent. You implement improvements identified during code review.
+
+Read these files:
+- .ai/<project-name>/<letter>/context.md - Codebase context
+- .ai/<project-name>/<letter>/plan.md - Original implementation plan
+- .ai/<project-name>/<letter>/review<R>.md - Code review with required changes
+
+Then read the source files mentioned in the review.
+
+YOUR TASK: Implement ALL changes listed in review<R>.md.
+
+For each issue in the review:
+1. Read the relevant source file(s).
+2. Make the specified change.
+3. Verify the change makes sense in context.
+
+After all changes are made:
+1. Build (from repository root): cmake --build ./out --config Debug --target Telegram
+2. If the build fails, fix build errors and rebuild until it passes.
+3. If build fails with file-locked errors (C1041, LNK1104), STOP and report - do not retry.
+
+Rules:
+- Implement exactly the changes from the review, nothing more.
+- Follow AGENTS.md coding conventions.
+- Do NOT modify .ai/ files.
+
+When finished, report what changes were made.
+```
+
+After the fix agent returns, increment R and loop back to Step 6a (unless R > 3, in which case proceed to Completion).
+
+## Completion
+
+When all phases including build verification and code review are done:
+1. Read the final `plan.md` and report the summary to the user.
+2. Show which files were modified/created.
+3. Note any issues encountered during implementation.
+4. Summarize code review iterations: how many rounds, what was found and fixed, or if it was approved on first pass.
+5. Calculate and display the total elapsed time since `$START_TIME` (format as `Xh Ym Zs`, omitting zero components — e.g. `12m 34s` or `1h 5m 12s`).
+6. Remind the user of the project name so they can use `/task <project-name> <follow-up description>` for follow-up changes.
+
+## Error Handling
+
+- If any agent fails or gets stuck, report the issue to the user and ask how to proceed.
+- If context.md or plan.md is not written properly by an agent, re-spawn that agent with more specific instructions.
+- If build errors persist after the build agent's attempts, report the remaining errors to the user.
+- If a review fix agent introduces new build errors that it cannot resolve, report to the user.
@@ -0,0 +1,656 @@
+---
+description: Implement a feature using multi-agent workflow, then iteratively test and fix it in-app
+allowed-tools: Read, Write, Edit, Glob, Grep, Bash, Task, AskUserQuestion, TodoWrite
+---
+
+# WithTest - Multi-Agent Implementation + Testing Workflow
+
+You orchestrate a multi-phase implementation workflow followed by an iterative testing/fixing loop. This is an extended version of `/task` that adds in-app programmatic testing after the build succeeds.
+
+**Arguments:** `$ARGUMENTS` = "$ARGUMENTS"
+
+If `$ARGUMENTS` is provided, it's the task description. If empty, ask the user what they want implemented.
+
+## Overview
+
+The workflow produces `.ai/<feature-name>/` containing:
+- `context.md` - Gathered codebase context relevant to the task
+- `plan.md` - Detailed implementation plan with phases and status
+- `testN.md` - Test plan for iteration N
+- `resultN.md` - Test result report for iteration N
+- `planN.md` - Fix plan for iteration N (if implementation bugs found)
+- `screenshots/` - Screenshots captured during test runs
+
+Two major stages:
+1. **Implementation** (Phases 0-5) - same as `/task`
+2. **Testing Loop** (Phase 6) - iterative test-plan → test-do → test-run → test-check cycle
+
+---
+
+## STAGE 1: IMPLEMENTATION (Phases 0-5)
+
+These phases are identical to the `/task` workflow.
+
+### Phase 0: Setup
+
+1. Understand the task from `$ARGUMENTS` or ask the user.
+2. **Follow-up detection:** Check if `$ARGUMENTS` starts with a task name (the first word/token before any whitespace or newline). Look for `.ai/<that-name>/` directory:
+   - If `.ai/<that-name>/` exists AND contains both `context.md` and `plan.md`, this is a **follow-up task**. Read both files. The rest of `$ARGUMENTS` (after the task name) is the follow-up task description describing what additional changes are needed.
+   - If no matching directory exists, this is a **new task** - proceed normally.
+3. For new tasks: check existing folders in `.ai/` to pick a unique short name (1-2 lowercase words, hyphen-separated) and create `.ai/<feature-name>/`.
+4. For follow-up tasks: the folder already exists, skip creation.
+
+### Follow-up Task Flow
+
+When a follow-up task is detected (existing `.ai/<name>/` with `context.md` and `plan.md`):
+
+1. Skip Phase 1 (Context Gathering) - context already exists.
+2. Skip Phase 2 (Planning) - original plan already exists.
+3. Go directly to **Phase 2F (Follow-up Planning)** instead of Phase 3.
+
+**Phase 2F: Follow-up Planning**
+
+Spawn an agent (Task tool, subagent_type=`general-purpose`) with this prompt:
+
+```
+You are a planning agent for a follow-up task on an existing implementation.
+
+Read these files:
+- .ai/<feature-name>/context.md - Previously gathered codebase context
+- .ai/<feature-name>/plan.md - Previous implementation plan (already completed)
+
+Then read the source files referenced in context.md and plan.md to understand what was already implemented.
+
+FOLLOW-UP TASK: <paste the follow-up task description here>
+
+The previous plan was already implemented and tested. Now there are follow-up changes needed.
+
+YOUR JOB:
+1. Understand what was already done from plan.md (look at the completed phases).
+2. Read the actual source files to see the current state of the code.
+3. If context.md needs updates for the follow-up task (new files relevant, new patterns needed), update it with additional sections marked "## Follow-up Context (iteration 2)" or similar.
+4. Create a NEW follow-up plan. Update plan.md by:
+   - Keep the existing content as history (do NOT delete it)
+   - Add a new section at the end:
+
+   ---
+   ## Follow-up Task
+   <description>
+
+   ## Follow-up Approach
+   <high-level description>
+
+   ## Follow-up Files to Modify
+   <list>
+
+   ## Follow-up Implementation Steps
+
+   ### Phase F1: <name>
+   1. <specific step>
+   2. ...
+
+   ### Phase F2: <name> (if needed)
+   ...
+
+   ## Follow-up Status
+   Phases: <N>
+   - [ ] Phase F1: <name>
+   - [ ] Phase F2: <name> (if applicable)
+   - [ ] Build verification
+   - [ ] Testing
+   Assessed: yes
+
+Reason carefully. The follow-up plan should be self-contained enough that an implementation agent can execute it by reading context.md and the updated plan.md.
+```
+
+After this agent completes, read `plan.md` to verify the follow-up plan was written. Then proceed to Phase 4 (Implementation), using the follow-up phases (F1, F2, etc.) instead of the original phases. After implementation and build verification, proceed to Stage 2 (Testing Loop) as normal.
+
+### New Task Flow
+
+When this is a new task (no existing folder), proceed with Phases 1-5 as described below.
+
+### Phase 1: Context Gathering
+
+Spawn an agent (Task tool, subagent_type=`general-purpose`) with this prompt structure:
+
+```
+You are a context-gathering agent for a large C++ codebase (Telegram Desktop).
+
+TASK: <paste the user's task description here>
+
+YOUR JOB: Read CLAUDE.md, inspect the codebase, find ALL files and code relevant to this task, and write a comprehensive context document.
+
+Steps:
+1. Read CLAUDE.md for project conventions and build instructions.
+2. Search the codebase for files, classes, functions, and patterns related to the task.
+3. Read all potentially relevant files. Be thorough - read more rather than less.
+4. For each relevant file, note:
+   - File path
+   - Relevant line ranges
+   - What the code does and how it relates to the task
+   - Key data structures, function signatures, patterns used
+5. Look for similar existing features that could serve as a reference implementation.
+6. Check api.tl if the task involves Telegram API.
+7. Check .style files if the task involves UI.
+8. Check lang.strings if the task involves user-visible text.
+
+Write your findings to: .ai/<feature-name>/context.md
+
+The context.md should contain:
+- **Task Description**: The full task restated clearly
+- **Relevant Files**: Every file path with line ranges and descriptions of what's there
+- **Key Code Patterns**: How similar things are done in the codebase (with code snippets)
+- **Data Structures**: Relevant types, structs, classes
+- **API Methods**: Any TL schema methods involved (copied from api.tl)
+- **UI Styles**: Any relevant style definitions
+- **Localization**: Any relevant string keys
+- **Build Info**: Build command and any special notes
+- **Reference Implementations**: Similar features that can serve as templates
+
+Be extremely thorough. Another agent with NO prior context will read this file and must be able to understand everything needed to implement the task.
+```
+
+After this agent completes, read `context.md` to verify it was written properly.
+
+### Phase 2: Planning
+
+Spawn an agent (Task tool, subagent_type=`general-purpose`) with this prompt structure:
+
+```
+You are a planning agent. You must create a detailed implementation plan.
+
+Read these files:
+- .ai/<feature-name>/context.md - Contains all gathered context
+- Then read the specific source files referenced in context.md to understand the code deeply.
+
+Think carefully about the implementation approach.
+
+Create a detailed plan in: .ai/<feature-name>/plan.md
+
+The plan.md should contain:
+
+## Task
+<one-line summary>
+
+## Approach
+<high-level description of the implementation approach>
+
+## Files to Modify
+<list of files that will be created or modified>
+
+## Files to Create
+<list of new files, if any>
+
+## Implementation Steps
+
+Each step must be specific enough that an agent can execute it without ambiguity:
+- Exact file paths
+- Exact function names
+- What code to add/modify/remove
+- Where exactly in the file (after which function, in which class, etc.)
+
+Number every step. Group steps into phases if there are more than ~8 steps.
+
+### Phase 1: <name>
+1. <specific step>
+2. <specific step>
+...
+
+### Phase 2: <name> (if needed)
+...
+
+## Build Verification
+- Build command to run
+- Expected outcome
+
+## Status
+- [ ] Phase 1: <name>
+- [ ] Phase 2: <name> (if applicable)
+- [ ] Build verification
+- [ ] Testing
+```
+
+After this agent completes, read `plan.md` to verify it was written properly.
+
+### Phase 3: Plan Assessment
+
+Spawn an agent (Task tool, subagent_type=`general-purpose`) with this prompt structure:
+
+```
+You are a plan assessment agent. Review and refine an implementation plan.
+
+Read these files:
+- .ai/<feature-name>/context.md
+- .ai/<feature-name>/plan.md
+- Then read the actual source files referenced to verify the plan makes sense.
+
+Carefully assess the plan:
+
+1. **Correctness**: Are the file paths and line references accurate? Does the plan reference real functions and types?
+2. **Completeness**: Are there missing steps? Edge cases not handled?
+3. **Code quality**: Will the plan minimize code duplication? Does it follow existing codebase patterns from CLAUDE.md?
+4. **Design**: Could the approach be improved? Are there better patterns already used in the codebase?
+5. **Phase sizing**: Each phase should be implementable by a single agent in one session. If a phase has more than ~8-10 substantive code changes, split it further.
+
+Update plan.md with your refinements. Keep the same structure but:
+- Fix any inaccuracies
+- Add missing steps
+- Improve the approach if you found better patterns
+- Ensure phases are properly sized for single-agent execution
+- Add a line at the top of the Status section: `Phases: <N>` indicating how many implementation phases there are
+- Add `Assessed: yes` at the bottom of the file
+
+If the plan is small enough for a single agent (roughly <=8 steps), mark it as a single phase.
+```
+
+After this agent completes, read `plan.md` to verify it was assessed.
+
+### Phase 4: Implementation
+
+Now read `plan.md` yourself to understand the phases.
+
+For each phase in the plan that is not yet marked as done, spawn an implementation agent (Task tool, subagent_type=`general-purpose`):
+
+```
+You are an implementation agent working on phase <N> of an implementation plan.
+
+Read these files first:
+- .ai/<feature-name>/context.md - Full codebase context
+- .ai/<feature-name>/plan.md - Implementation plan
+
+Then read the source files you'll be modifying.
+
+YOUR TASK: Implement ONLY Phase <N> from the plan:
+<paste the specific phase steps here>
+
+Rules:
+- Follow the plan precisely
+- Follow CLAUDE.md coding conventions (no comments except complex algorithms, use auto, empty line before closing brace, etc.)
+- Do NOT modify .ai/ files except to update the Status section in plan.md
+- When done, update plan.md Status section: change `- [ ] Phase <N>: ...` to `- [x] Phase <N>: ...`
+- Do NOT work on other phases
+
+When finished, report what you did and any issues encountered.
+```
+
+After each implementation agent returns:
+1. Read `plan.md` to check the status was updated.
+2. If more phases remain, spawn the next implementation agent.
+3. If all phases are done, proceed to build verification.
+
+### Phase 5: Build Verification
+
+Spawn a build verification agent (Task tool, subagent_type=`general-purpose`):
+
+```
+You are a build verification agent.
+
+Read these files:
+- .ai/<feature-name>/context.md
+- .ai/<feature-name>/plan.md
+
+The implementation is complete. Your job is to build the project and fix any build errors.
+
+Steps:
+1. Run: cmake --build "c:\Telegram\tdesktop\out" --config Debug --target Telegram
+2. If the build succeeds, update plan.md: change `- [ ] Build verification` to `- [x] Build verification`
+3. If the build fails:
+   a. Read the error messages carefully
+   b. Read the relevant source files
+   c. Fix the errors in accordance with the plan and CLAUDE.md conventions
+   d. Rebuild and repeat until the build passes
+   e. Update plan.md status when done
+
+Rules:
+- Only fix build errors, do not refactor or improve code
+- Follow CLAUDE.md conventions
+- If build fails with file-locked errors (C1041, LNK1104), STOP and report - do not retry
+
+When finished, report the build result.
+```
+
+After the build agent returns, read `plan.md` to confirm build verification passed. If it did, proceed to Stage 2.
+
+---
+
+## STAGE 2: TESTING LOOP (Phase 6)
+
+This stage iteratively tests the implementation in-app and fixes issues. It maintains an iteration counter `N` starting at 1.
+
+**Key concept:** Since the project has tight coupling and no unit test infrastructure, we test by injecting `#ifdef _DEBUG` blocks into the app code that perform actions, write to `log.txt`, save screenshots, and call `Core::Quit()` when done. An agent then runs the app and observes the output.
+
+### Git Submodule Awareness
+
+Before ANY git operation (commit, stash, stash pop), the agent must:
+1. Run `git submodule status` to check for modified submodules.
+2. If submodules have changes, commit/stash those submodules FIRST, individually:
+   ```
+   cd <submodule-path> && git add -A && git commit -m "[wip-N] test changes" && cd <repo-root>
+   ```
+   or for stash:
+   ```
+   cd <submodule-path> && git stash && cd <repo-root>
+   ```
+3. Then operate on the main repo.
+
+### Step 6a: Test Plan (test-plan agent)
+
+Spawn an agent (Task tool, subagent_type=`general-purpose`):
+
+```
+You are a test-planning agent for Telegram Desktop (C++ / Qt).
+
+Read these files:
+- .ai/<feature-name>/context.md
+- .ai/<feature-name>/plan.md
+<if N > 1, also include:>
+- .ai/<feature-name>/result<N-1>.md - Previous test result
+<if a planN.md triggered this iteration:>
+- .ai/<feature-name>/plan<trigger>.md - Fix plan that was just implemented
+
+CURRENT ITERATION: <N>
+
+YOUR TASKS:
+
+1. **Commit current implementation changes.**
+   - Run `git submodule status` to check for modified submodules.
+   - If any submodules are dirty, go into each one and commit:
+     `cd <submodule> && git add -A && git commit -m "[wip-<N>]" && cd <repo-root>`
+   - Then in main repo: `git add -A && git commit -m "[wip-<N>]"`
+   - Do NOT add files in .ai/ to the commit.
+
+2. <If N > 1> **Restore previous test code.**
+   - Run `git submodule status` and `git stash list` in any dirty submodules to check for stashed test code.
+   - Pop submodule stashes first: `cd <submodule> && git stash pop && cd <repo-root>`
+   - Then pop main repo stash: `git stash pop`
+   - Read the previous test<N-1>.md to understand what was tested before.
+   - Decide: reuse/modify existing test code or start fresh.
+
+3. **Plan the test code.**
+   Carefully design test code that will verify the implementation works correctly.
+
+   The test code must:
+   - Be wrapped in `#ifdef _DEBUG` blocks so it only runs in Debug builds
+   - Be injected at appropriate points in the app lifecycle (e.g., after main window shows, after chats load, etc.)
+   - Write progress and results to a log file. Use a dedicated path like:
+     `QFile logFile("c:/Telegram/tdesktop/.ai/<feature-name>/test_log.txt");`
+     Open with `QIODevice::Append | QIODevice::Text`, write with QTextStream, and flush after every write.
+   - Save screenshots where visual verification is needed:
+     `widget->grab().save("c:/Telegram/tdesktop/.ai/<feature-name>/screenshots/<name>.png");`
+     Log each screenshot save: `"SCREENSHOT: <full-path>"`
+   - Use `QTimer::singleShot(...)` or deferred calls to schedule test steps after UI events settle
+   - Call `Core::Quit()` when all test steps complete, so the app exits cleanly
+   - Log `"TEST_COMPLETE"` right before `Core::Quit()` so the test-run agent knows testing finished
+   - Log `"TEST_STEP: <description>"` before each major step for progress tracking
+   - Log `"TEST_RESULT: PASS: <what>"` or `"TEST_RESULT: FAIL: <what> - <details>"` for each check
+
+   Consider what needs testing:
+   - Does the new UI appear correctly?
+   - Do interactions work (clicks, navigation)?
+   - Does data flow correctly?
+   - Are there edge cases to verify?
+
+4. **Write the test plan** to `.ai/<feature-name>/test<N>.md` containing:
+
+   ## Test Iteration <N>
+   ## What We're Testing
+   <description of what this test verifies>
+
+   ## Test Steps
+   1. <step>: what we do, what we expect, how we verify
+   2. ...
+
+   ## Code Injection Points
+   - File: <path>, Location: <where in file>, Purpose: <what this block does>
+   - ...
+
+   ## Expected Log Output
+   <example of what test_log.txt should contain if everything works>
+
+   ## Expected Screenshots
+   - <name>.png: should show <description>
+   - ...
+
+   ## Success Criteria
+   - <criterion 1>
+   - <criterion 2>
+   - ...
+
+When finished, report what test plan was created.
+```
+
+### Step 6b: Test Implementation (test-do agent)
+
+Spawn an agent (Task tool, subagent_type=`general-purpose`):
+
+```
+You are a test implementation agent for Telegram Desktop (C++ / Qt).
+
+Read these files:
+- .ai/<feature-name>/context.md
+- .ai/<feature-name>/plan.md
+- .ai/<feature-name>/test<N>.md - The test plan to implement
+
+YOUR TASK: Implement the test code described in test<N>.md.
+
+Rules:
+- ALL test code MUST be inside `#ifdef _DEBUG` blocks
+- Place test code at the injection points specified in the test plan
+- Make sure the screenshots folder exists: create `.ai/<feature-name>/screenshots/` directory
+- Delete any old test_log.txt before the test starts (in code, at the first test step)
+- Use QTimer::singleShot for delayed operations to let the UI settle
+- Flush log writes immediately (don't buffer)
+- End with logging "TEST_COMPLETE" and calling Core::Quit()
+- Follow CLAUDE.md coding conventions
+- Make sure the code compiles: run `cmake --build "c:\Telegram\tdesktop\out" --config Debug --target Telegram`
+- If build fails, fix errors and rebuild until it passes
+- If build fails with file-locked errors (C1041, LNK1104), STOP and report
+
+When finished, report what test code was added and where.
+```
+
+### Step 6c: Test Run (test-run agent)
+
+Spawn an agent (Task tool, subagent_type=`general-purpose`):
+
+```
+You are a test execution agent. You run the Telegram Desktop app and observe test output.
+
+Read these files:
+- .ai/<feature-name>/test<N>.md - The test plan (so you know what to expect)
+
+YOUR TASK: Run the built app and monitor test execution.
+
+Steps:
+
+1. **Prepare.**
+   - Delete old test_log.txt if it exists: `del "c:\Telegram\tdesktop\docs\ai\work\<feature-name>\test_log.txt" 2>nul`
+   - Ensure screenshots folder exists: `mkdir "c:\Telegram\tdesktop\docs\ai\work\<feature-name>\screenshots" 2>nul`
+
+2. **Launch the app.**
+   - Run in background: `start "" "c:\Telegram\tdesktop\out\Debug\Telegram.exe"`
+   - Note the time of launch.
+
+3. **Monitor test_log.txt in a polling loop.**
+   - Every 5 seconds, read the log file to check for new output.
+   - When you see `"SCREENSHOT: <path>"`, read the screenshot image file to visually verify it.
+   - Track which TEST_STEP entries appear.
+   - Track TEST_RESULT entries (PASS/FAIL).
+
+4. **Detect completion or failure.**
+   - **Success**: Log contains `"TEST_COMPLETE"` - the app should exit on its own shortly after.
+   - **Crash**: The process disappears before `"TEST_COMPLETE"`. Check for crash dumps or error dialogs.
+   - **Hang/Timeout**: If no new log output for 120 seconds and no `"TEST_COMPLETE"`, kill the process:
+     `taskkill /IM Telegram.exe /F`
+   - **No log at all**: If no test_log.txt appears within 60 seconds of launch, kill the process.
+
+5. **After the process exits (or is killed), wait 5 seconds, then:**
+   - Read the full final test_log.txt
+   - Read all screenshot files saved during the test
+   - Check for any leftover Telegram.exe processes: `tasklist /FI "IMAGENAME eq Telegram.exe"` and kill if needed
+
+6. **Write the result report** to `.ai/<feature-name>/result<N>.md`:
+
+   ## Test Result - Iteration <N>
+   ## Outcome: <PASS / FAIL / CRASH / TIMEOUT>
+
+   ## Log Output
+   <full contents of test_log.txt, or note that it was empty/missing>
+
+   ## Screenshot Analysis
+   - <name>.png: <description of what you see, whether it matches expectations from test<N>.md>
+   - ...
+
+   ## Test Results Summary
+   - PASS: <list>
+   - FAIL: <list>
+
+   ## Issues Found
+   <any problems observed, unexpected behavior, etc.>
+
+   ## Raw Details
+   <process exit code if available, timing information, any stderr output>
+
+When finished, report the test outcome.
+```
+
+After the test-run agent returns, read `result<N>.md`.
+
+### Step 6d: Test Assessment (test-check agent)
+
+Spawn an agent (Task tool, subagent_type=`general-purpose`):
+
+```
+You are a test assessment agent. You analyze test results and decide next steps.
+
+Read these files:
+- .ai/<feature-name>/context.md
+- .ai/<feature-name>/plan.md
+- .ai/<feature-name>/test<N>.md
+- .ai/<feature-name>/result<N>.md
+<if N > 1, also read previous test/result pairs for history>
+
+Carefully analyze the test results.
+
+DECIDE one of three outcomes:
+
+### Outcome A: ALL TESTS PASS
+If all test results are PASS and screenshots look correct:
+1. Write to result<N>.md (append): `\n## Verdict: PASS`
+2. Report "ALL_TESTS_PASS" so the orchestrator knows to finish.
+
+### Outcome B: TEST CODE NEEDS CHANGES
+If the test itself was flawed (wrong assertions, bad timing, insufficient waits, screenshot taken too early, wrong injection point, etc.) but the implementation seems correct:
+1. Describe what's wrong with the test and what to change.
+2. Make the changes directly to the test code in the source files.
+3. Rebuild: `cmake --build "c:\Telegram\tdesktop\out" --config Debug --target Telegram`
+4. If build fails with file-locked errors (C1041, LNK1104), STOP and report.
+5. Write the updated test description to `.ai/<feature-name>/test<N+1>.md` explaining what changed and why.
+6. Report "TEST_NEEDS_RERUN" so the orchestrator goes back to step 6c.
+
+### Outcome C: IMPLEMENTATION HAS BUGS
+If the test results indicate actual bugs in the implementation (not test issues):
+1. Analyze what's wrong with the implementation.
+2. Write a fix plan to `.ai/<feature-name>/plan<N>.md`:
+
+   ## Fix Plan - Iteration <N>
+   ## Problem
+   <what the test revealed>
+
+   ## Root Cause
+   <analysis of why the implementation is wrong>
+
+   ## Fix Steps
+   1. <specific fix with file path, location, what to change>
+   2. ...
+
+3. Stash the test code (it will be restored later):
+   - Run `git submodule status` and stash dirty submodules first:
+     `cd <submodule> && git stash && cd <repo-root>`
+   - Then: `git stash`
+4. Report "IMPLEMENTATION_NEEDS_FIX" so the orchestrator goes to re-implementation.
+
+When finished, report your verdict clearly as one of: ALL_TESTS_PASS, TEST_NEEDS_RERUN, IMPLEMENTATION_NEEDS_FIX.
+```
+
+### Orchestrator Loop Logic
+
+After Phase 5 (build verification) succeeds, you (the orchestrator) run the testing loop:
+
+```
+Set N = 1
+
+LOOP:
+  1. Spawn test-plan agent (Step 6a) with iteration N
+  2. Spawn test-do agent (Step 6b) with iteration N
+  3. Spawn test-run agent (Step 6c) with iteration N
+  4. Spawn test-check agent (Step 6d) with iteration N
+  5. Read the verdict:
+     - "ALL_TESTS_PASS" → go to FINISH
+     - "TEST_NEEDS_RERUN" →
+         N = N + 1
+         go to step 3 (skip 6a and 6b, test code was already updated by test-check)
+     - "IMPLEMENTATION_NEEDS_FIX" →
+         Spawn implementation fix agent (see below)
+         N = N + 1
+         go to step 1 (full restart: new commit, stash pop test code, etc.)
+  6. Safety: if N > 5, stop and report to user - too many iterations.
+
+FINISH:
+  - Stash or revert all test code (#ifdef _DEBUG blocks):
+    - git submodule status, stash submodules if dirty
+    - git stash (to save test code separately, user may want it later)
+  - Update plan.md: change `- [ ] Testing` to `- [x] Testing`
+  - Report to user
+```
+
+### Implementation Fix Agent
+
+When test-check reports IMPLEMENTATION_NEEDS_FIX, spawn this agent:
+
+```
+You are an implementation fix agent.
+
+Read these files:
+- .ai/<feature-name>/context.md
+- .ai/<feature-name>/plan.md
+- .ai/<feature-name>/plan<N>.md - The fix plan from test assessment
+
+Then read the source files mentioned in the fix plan.
+
+YOUR TASK: Implement the fixes described in plan<N>.md.
+
+Steps:
+1. Read and understand the fix plan.
+2. Make the specified code changes.
+3. Build: `cmake --build "c:\Telegram\tdesktop\out" --config Debug --target Telegram`
+4. Fix any build errors.
+5. If build fails with file-locked errors (C1041, LNK1104), STOP and report.
+
+Rules:
+- Only make changes specified in the fix plan
+- Follow CLAUDE.md conventions
+- Do NOT touch test code or .ai/ files (except plan.md status if relevant)
+
+When finished, report what was fixed.
+```
+
+---
+
+## Completion
+
+When the testing loop finishes (ALL_TESTS_PASS or user stops it):
+1. Read the final `plan.md` and report full summary to the user.
+2. List all files modified/created by the implementation.
+3. Summarize test iterations: how many rounds, what was found and fixed.
+4. Note that test code is stashed (available via `git stash pop` if needed).
+5. Note any remaining concerns.
+
+## Error Handling
+
+- If any agent fails or gets stuck, report the issue to the user and ask how to proceed.
+- If context.md or plan.md is not written properly by an agent, re-spawn that agent with more specific instructions.
+- If build errors persist after agent attempts, report remaining errors to the user.
+- If the testing loop exceeds 5 iterations, stop and report - something fundamental may be wrong.
+- If the app crashes repeatedly, report to user - may need manual investigation.
+- If file-locked build errors occur at ANY point, stop immediately and ask user to close Telegram.exe.
@@ -0,0 +1,11 @@
+param([string]$outPath)
+Add-Type -AssemblyName System.Windows.Forms
+$img = [System.Windows.Forms.Clipboard]::GetImage()
+if ($img) {
+    $img.Save($outPath, [System.Drawing.Imaging.ImageFormat]::Png)
+    Write-Host "Saved to $outPath"
+    exit 0
+} else {
+    Write-Host "No image on clipboard"
+    exit 1
+}
@@ -0,0 +1,28 @@
+#!/bin/bash
+# Grab clipboard image on macOS and save as PNG.
+outPath="$1"
+if [ -z "$outPath" ]; then
+    echo "Usage: grab_clipboard.sh <output.png>"
+    exit 1
+fi
+
+osascript -e '
+set theFile to POSIX file "'"$outPath"'"
+try
+    set theImage to the clipboard as «class PNGf»
+on error
+    return "no image"
+end try
+set fh to open for access theFile with write permission
+write theImage to fh
+close access fh
+return "ok"
+' 2>/dev/null | grep -q "ok"
+
+if [ $? -eq 0 ]; then
+    echo "Saved to $outPath"
+    exit 0
+else
+    echo "No image on clipboard"
+    exit 1
+fi
@@ -0,0 +1,343 @@
+#!/usr/bin/env pwsh
+# Iterative Task Runner
+# Runs Claude Code in a loop to complete tasks from a taskplanner-created folder
+#
+# Usage: .\docs\ai\iterate.ps1 <featurename> [-MaxIterations N] [-Interactive] [-DryRun] [-SingleCommit] [-NoCommit]
+#
+# Arguments:
+#   featurename     Name of the folder in .ai/ containing prompt.md and tasks.json
+#   -MaxIterations  Maximum iterations before stopping (default: 50)
+#   -Interactive    Pause between iterations for user confirmation (default: auto/no pause)
+#   -DryRun         Show what would be executed without running
+#   -SingleCommit   Don't commit after each task, commit all changes at the end
+#   -NoCommit       Don't commit at all (no per-task commits, no final commit)
+
+param(
+    [Parameter(Position=0, Mandatory=$true)]
+    [string]$FeatureName,
+
+    [int]$MaxIterations = 50,
+    [switch]$Interactive,
+    [switch]$DryRun,
+    [switch]$SingleCommit,
+    [switch]$NoCommit
+)
+
+$ErrorActionPreference = "Stop"
+
+$ScriptDir = Split-Path -Parent $MyInvocation.MyCommand.Path
+$RepoRoot = Resolve-Path (Join-Path $ScriptDir "..\..")
+$WorkDir = Join-Path $ScriptDir "work\$FeatureName"
+$PromptMd = Join-Path $WorkDir "prompt.md"
+$TasksJson = Join-Path $WorkDir "tasks.json"
+
+$BuildOutputDir = Join-Path $RepoRoot "out\Debug"
+$TelegramExe = Join-Path $BuildOutputDir "Telegram.exe"
+$TelegramPdb = Join-Path $BuildOutputDir "Telegram.pdb"
+
+function Format-Duration {
+    param([int]$Seconds)
+
+    if ($Seconds -lt 60) {
+        return "${Seconds}s"
+    } elseif ($Seconds -lt 3600) {
+        $min = [math]::Floor($Seconds / 60)
+        $sec = $Seconds % 60
+        return "${min}m ${sec}s"
+    } else {
+        $hr = [math]::Floor($Seconds / 3600)
+        $min = [math]::Floor(($Seconds % 3600) / 60)
+        $sec = $Seconds % 60
+        return "${hr}h ${min}m ${sec}s"
+    }
+}
+
+function Test-BuildFilesUnlocked {
+    $filesToCheck = @($TelegramExe, $TelegramPdb)
+
+    foreach ($file in $filesToCheck) {
+        if (Test-Path $file) {
+            try {
+                Remove-Item $file -Force -ErrorAction Stop
+                Write-Host "Removed: $file" -ForegroundColor DarkGray
+            }
+            catch {
+                Write-Host ""
+                Write-Host "========================================" -ForegroundColor Red
+                Write-Host "  ERROR: Cannot delete build output" -ForegroundColor Red
+                Write-Host "  File is locked: $file" -ForegroundColor Red
+                Write-Host "" -ForegroundColor Red
+                Write-Host "  Please close Telegram.exe and any" -ForegroundColor Red
+                Write-Host "  debugger, then try again." -ForegroundColor Red
+                Write-Host "========================================" -ForegroundColor Red
+                Write-Host ""
+                return $false
+            }
+        }
+    }
+    return $true
+}
+
+function Show-ClaudeStream {
+    param([string]$Line)
+
+    try {
+        $obj = $Line | ConvertFrom-Json -ErrorAction Stop
+
+        switch ($obj.type) {
+            "assistant" {
+                if ($obj.message.content) {
+                    foreach ($block in $obj.message.content) {
+                        if ($block.type -eq "text") {
+                            Write-Host $block.text -ForegroundColor White
+                        }
+                        elseif ($block.type -eq "tool_use") {
+                            $summary = ""
+                            if ($block.input) {
+                                if ($block.input.file_path) {
+                                    $summary = $block.input.file_path
+                                } elseif ($block.input.pattern) {
+                                    $summary = $block.input.pattern
+                                } elseif ($block.input.command) {
+                                    $cmd = $block.input.command
+                                    if ($cmd.Length -gt 60) { $cmd = $cmd.Substring(0, 60) + "..." }
+                                    $summary = $cmd
+                                } else {
+                                    $inputStr = $block.input | ConvertTo-Json -Compress -Depth 1
+                                    if ($inputStr.Length -gt 60) { $inputStr = $inputStr.Substring(0, 60) + "..." }
+                                    $summary = $inputStr
+                                }
+                            }
+                            Write-Host "[Tool: $($block.name)] $summary" -ForegroundColor Yellow
+                        }
+                    }
+                }
+            }
+            "user" {
+                # Tool results - skip verbose output
+            }
+            "result" {
+                Write-Host "`n--- Session Complete ---" -ForegroundColor Cyan
+                if ($obj.cost_usd) {
+                    Write-Host "Cost: `$$($obj.cost_usd)" -ForegroundColor DarkCyan
+                }
+            }
+            "system" {
+                # System messages - skip
+            }
+        }
+    }
+    catch {
+        # Not valid JSON, skip
+    }
+}
+
+# Verify feature folder exists
+if (-not (Test-Path $WorkDir)) {
+    Write-Error "Feature folder not found: $WorkDir`nRun '/taskplanner $FeatureName' first to create it."
+    exit 1
+}
+
+# Verify required files exist
+foreach ($file in @($PromptMd, $TasksJson)) {
+    if (-not (Test-Path $file)) {
+        Write-Error "Required file not found: $file"
+        exit 1
+    }
+}
+
+if ($SingleCommit -or $NoCommit) {
+    $AfterImplementation = @"
+   - Mark the task completed in tasks.json ("completed": true)
+   - If new tasks emerged, add them to tasks.json
+"@
+    $CommitRule = "- Do NOT commit changes after task is done, just mark it as done in tasks.json. Commit will be done when all tasks are complete, separately."
+} else {
+    $AfterImplementation = @"
+   - Mark the task completed in tasks.json ("completed": true)
+   - Commit your changes
+   - If new tasks emerged, add them to tasks.json
+"@
+    $CommitRule = ""
+}
+
+$Prompt = @"
+You are an autonomous coding agent working on: $FeatureName
+
+Read these files for context:
+- .ai/$FeatureName/prompt.md - Detailed instructions and architecture
+- .ai/$FeatureName/tasks.json - Task list with completion status
+
+Do exactly ONE task per iteration.
+
+## Steps
+
+1. Read tasks.json and find the most suitable task to implement (it can be first uncompleted task or it can be some task in the middle, if it is better suited to be implemented right now, respecting dependencies)
+2. Plan the implementation carefully
+3. Implement that ONE task only
+4. After successful implementation:
+$AfterImplementation
+
+## Critical Rules
+
+- Only mark a task complete if you verified the work is done (build passes, etc.)
+- If stuck, document the issue in the task's notes field and move on
+- Do ONE task per iteration, then stop
+- NEVER try to commit files in .ai/
+$CommitRule
+
+## Completion Signal
+
+If ALL tasks in tasks.json have "completed": true, output exactly:
+===ALL_TASKS_COMPLETE===
+"@
+
+$CommitPrompt = @"
+You are an autonomous coding agent. All tasks for "$FeatureName" are now complete.
+
+Your job: Create a single commit with all the changes.
+
+## Steps
+
+1. Run git status to see all modified files
+2. Run git diff to review the changes
+3. Create a commit with a short summary (aim for ~50 chars, max 76 chars) describing what was implemented
+4. The commit message should describe the overall feature/fix, not list individual changes
+
+## Critical Rules
+
+- NEVER try to commit files in .ai/
+- Use a concise commit message that captures the essence of the work done
+"@
+
+Write-Host ""
+Write-Host "========================================" -ForegroundColor Cyan
+Write-Host "  Iterative Task Runner" -ForegroundColor Cyan
+Write-Host "  Feature: $FeatureName" -ForegroundColor Cyan
+Write-Host "  Max iterations: $MaxIterations" -ForegroundColor Cyan
+Write-Host "  Mode: $(if ($Interactive) { 'Interactive' } else { 'Auto' })" -ForegroundColor Cyan
+Write-Host "  Commit: $(if ($NoCommit) { 'None' } elseif ($SingleCommit) { 'Single (at end)' } else { 'Per task' })" -ForegroundColor Cyan
+Write-Host "  Working directory: $RepoRoot" -ForegroundColor Cyan
+Write-Host "========================================" -ForegroundColor Cyan
+Write-Host ""
+
+if ($DryRun) {
+    Write-Host "[DRY RUN] Would execute with prompt:" -ForegroundColor Yellow
+    Write-Host $Prompt
+    Write-Host ""
+    Write-Host "Feature folder: $WorkDir" -ForegroundColor Yellow
+    Write-Host "Prompt file: $PromptMd" -ForegroundColor Yellow
+    Write-Host "Tasks file: $TasksJson" -ForegroundColor Yellow
+    exit 0
+}
+
+Push-Location $RepoRoot
+
+$ScriptStartTime = Get-Date
+$IterationTimes = @()
+
+try {
+    for ($i = 1; $i -le $MaxIterations; $i++) {
+        Write-Host ""
+        Write-Host "========================================" -ForegroundColor Yellow
+        Write-Host "  Iteration $i of $MaxIterations" -ForegroundColor Yellow
+        Write-Host "========================================" -ForegroundColor Yellow
+        Write-Host ""
+
+        if (-not (Test-BuildFilesUnlocked)) {
+            exit 1
+        }
+
+        $IterationStartTime = Get-Date
+
+        claude --dangerously-skip-permissions --verbose -p $Prompt --output-format stream-json 2>&1 | ForEach-Object {
+            Show-ClaudeStream $_
+        }
+
+        $IterationEndTime = Get-Date
+        $IterationDuration = [int]($IterationEndTime - $IterationStartTime).TotalSeconds
+        $IterationTimes += $IterationDuration
+        Write-Host "Iteration time: $(Format-Duration $IterationDuration)" -ForegroundColor DarkCyan
+
+        # Check task status after each run
+        $tasks = Get-Content $TasksJson | ConvertFrom-Json
+        $incomplete = @($tasks.tasks | Where-Object { -not $_.completed })
+        $inProgress = @($tasks.tasks | Where-Object { $_.started -and -not $_.completed })
+
+        if ($incomplete.Count -eq 0) {
+            if ($SingleCommit -and -not $NoCommit) {
+                $i++
+                if ($i -le $MaxIterations) {
+                    Write-Host ""
+                    Write-Host "========================================" -ForegroundColor Yellow
+                    Write-Host "  Final commit iteration" -ForegroundColor Yellow
+                    Write-Host "========================================" -ForegroundColor Yellow
+                    Write-Host ""
+
+                    $CommitStartTime = Get-Date
+
+                    claude --dangerously-skip-permissions --verbose -p $CommitPrompt --output-format stream-json 2>&1 | ForEach-Object {
+                        Show-ClaudeStream $_
+                    }
+
+                    $CommitEndTime = Get-Date
+                    $CommitDuration = [int]($CommitEndTime - $CommitStartTime).TotalSeconds
+                    $IterationTimes += $CommitDuration
+                    Write-Host "Commit time: $(Format-Duration $CommitDuration)" -ForegroundColor DarkCyan
+                } else {
+                    Write-Host ""
+                    Write-Host "========================================" -ForegroundColor Red
+                    Write-Host "  Max iterations reached before commit" -ForegroundColor Red
+                    Write-Host "  Run manually: git add . && git commit" -ForegroundColor Red
+                    Write-Host "========================================" -ForegroundColor Red
+                    Write-Host ""
+                    exit 1
+                }
+            }
+
+            $TotalTime = [int]((Get-Date) - $ScriptStartTime).TotalSeconds
+            $AvgTime = if ($IterationTimes.Count -gt 0) { [int](($IterationTimes | Measure-Object -Sum).Sum / $IterationTimes.Count) } else { 0 }
+
+            Write-Host ""
+            Write-Host "========================================" -ForegroundColor Green
+            Write-Host "  ALL TASKS COMPLETE!" -ForegroundColor Green
+            Write-Host "  Feature: $FeatureName" -ForegroundColor Green
+            Write-Host "  Iterations: $($IterationTimes.Count)" -ForegroundColor Green
+            Write-Host "  Total time: $(Format-Duration $TotalTime)" -ForegroundColor Green
+            Write-Host "  Avg per iteration: $(Format-Duration $AvgTime)" -ForegroundColor Green
+            Write-Host "========================================" -ForegroundColor Green
+            Write-Host ""
+
+            exit 0
+        }
+
+        Write-Host ""
+        Write-Host "Remaining tasks: $($incomplete.Count)" -ForegroundColor Cyan
+        if ($inProgress.Count -gt 0) {
+            Write-Host "In progress: $($inProgress[0].title)" -ForegroundColor Yellow
+        }
+
+        if ($Interactive) {
+            Write-Host "Press Enter to continue, Ctrl+C to stop..." -ForegroundColor Cyan
+            Read-Host
+        } else {
+            Start-Sleep -Seconds 2
+        }
+    }
+
+    $TotalTime = [int]((Get-Date) - $ScriptStartTime).TotalSeconds
+    $AvgTime = if ($IterationTimes.Count -gt 0) { [int](($IterationTimes | Measure-Object -Sum).Sum / $IterationTimes.Count) } else { 0 }
+
+    Write-Host ""
+    Write-Host "========================================" -ForegroundColor Red
+    Write-Host "  Max iterations ($MaxIterations) reached" -ForegroundColor Red
+    Write-Host "  Check tasks.json for remaining tasks" -ForegroundColor Red
+    Write-Host "  Total time: $(Format-Duration $TotalTime)" -ForegroundColor Red
+    Write-Host "  Avg per iteration: $(Format-Duration $AvgTime)" -ForegroundColor Red
+    Write-Host "========================================" -ForegroundColor Red
+    Write-Host ""
+    exit 1
+}
+finally {
+    Pop-Location
+}
@@ -1,105 +0,0 @@
---
-description: For tasks requiring sending Telegram server API requests or working with generated API types.
-globs:
-alwaysApply: false
---
-# Telegram Desktop API Usage
-
-## API Schema
-
-The API definitions are described using [TL Language]\(https:/core.telegram.org/mtproto/TL) in two main schema files:
-
-1.  **`Telegram/SourceFiles/mtproto/scheme/mtproto.tl`**
-    *   Defines the core MTProto protocol types and methods used for basic communication, encryption, authorization, service messages, etc.
-    *   Some fundamental types and methods from this schema (like basic types, RPC calls, containers) are often implemented directly in the C++ MTProto core (`SourceFiles/mtproto/`) and may be skipped during the C++ code generation phase.
-    *   Other parts of `mtproto.tl` might still be processed by the code generator.
-
-2.  **`Telegram/SourceFiles/mtproto/scheme/api.tl`**
-    *   Defines the higher-level Telegram API layer, including all the methods and types related to chat functionality, user profiles, messages, channels, stickers, etc.
-    *   This is the primary schema used when making functional API requests within the application.
-
-Both files use the same TL syntax to describe API methods (functions) and types (constructors).
-
-## Code Generation
-
-A custom code generation tool processes `api.tl` (and parts of `mtproto.tl`) to create corresponding C++ classes and types. These generated headers are typically included via the Precompiled Header (PCH) for the main `Telegram` project.
-
-Generated types often follow the pattern `MTP[Type]` (e.g., `MTPUser`, `MTPMessage`) and methods correspond to functions within the `MTP` namespace or related classes (e.g., `MTPmessages_SendMessage`).
-
-## Making API Requests
-
-API requests are made using a standard pattern involving the `api()` object (providing access to the `MTP::Instance`), the generated `MTP...` request object, callback handlers for success (`.done()`) and failure (`.fail()`), and the `.send()` method.
-
-Here's the general structure:
-
-```cpp
-// Include necessary headers if not already in PCH
-
-// Obtain the API instance (usually via api() or MTP::Instance::Get())
-api().request(MTPnamespace_MethodName(
-    // Constructor arguments based on the api.tl definition for the method
-    MTP_flags(flags_value),      // Use MTP_flags if the method has flags
-    MTP_inputPeer(peer),         // Use MTP_... types for parameters
-    MTP_string(messageText),
-    MTP_long(randomId),
-    // ... other arguments matching the TL definition
-    MTP_vector<MTPMessageEntity>() // Example for a vector argument
-)).done([=]\(const MTPResponseType &result) {
-    // Handle the successful response (result).
-    // 'result' will be of the C++ type corresponding to the TL type
-    // specified after the '=' in the api.tl method definition.
-    // How to access data depends on whether the TL type has one or multiple constructors:
-
-    // 1. Multiple Constructors (e.g., User = User | UserEmpty):
-    //    Use .match() with lambdas for each constructor:
-    result.match([&]\(const MTPDuser &data) {
-        /* use data.vfirst_name().v, etc. */
-    }, [&]\(const MTPDuserEmpty &data) {
-        /* handle empty user */
-    });
-
-    //    Alternatively, check the type explicitly and use the constructor getter:
-    if (result.type() == mtpc_user) {
-        const auto &data = result.c_user(); // Asserts if type is not mtpc_user!
-        // use data.vfirst_name().v
-    } else if (result.type() == mtpc_userEmpty) {
-        const auto &data = result.c_userEmpty();
-        // handle empty user
-    }
-
-    // 2. Single Constructor (e.g., Messages = messages { msgs: vector<Message> }):
-    //    Use .match() with a single lambda:
-    result.match([&]\(const MTPDmessages &data) { /* use data.vmessages().v */ });
-
-    //    Or check the type explicitly and use the constructor getter:
-    if (result.type() == mtpc_messages) {
-        const auto &data = result.c_messages(); // Asserts if type is not mtpc_messages!
-        // use data.vmessages().v
-    }
-
-    //    Or use the shortcut .data() for single-constructor types:
-    const auto &data = result.data(); // Only works for single-constructor types!
-    // use data.vmessages().v
-
-}).fail([=]\(const MTP::Error &error) {
-    // Handle the API error (error).
-    // 'error' is an MTP::Error object containing the error code (error.type())
-    // and description (error.description()). Check for specific error strings.
-    if (error.type() == u"FLOOD_WAIT_X"_q) {
-        // Handle flood wait
-    } else {
-        Ui::show(Box<InformBox>(Lang::Hard::ServerError())); // Example generic error handling
-    }
-}).handleFloodErrors().send(); // handleFloodErrors() is common, then send()
-```
-
-**Key Points:**
-
-*   Always refer to `Telegram/SourceFiles/mtproto/scheme/api.tl` for the correct method names, parameters (names and types), and response types.
-*   Use the generated `MTP...` types/classes for request parameters (e.g., `MTP_int`, `MTP_string`, `MTP_bool`, `MTP_vector`, `MTPInputUser`, etc.) and response handling.
-*   The `.done()` lambda receives the specific C++ `MTP...` type corresponding to the TL return type.
-    *   For types with **multiple constructors** (e.g., `User = User | UserEmpty`), use `result.match([&]\(const MTPDuser &d){ ... }, [&]\(const MTPDuserEmpty &d){ ... })` to handle each case, or check `result.type() == mtpc_user` / `mtpc_userEmpty` and call the specific `result.c_user()` / `result.c_userEmpty()` getter (which asserts on type mismatch).
-    *   For types with a **single constructor** (e.g., `Messages = messages{...}`), you can use `result.match([&]\(const MTPDmessages &d){ ... })` with one lambda, or check `type()` and call `c_messages()`, or use the shortcut `result.data()` to access the fields directly.
-*   The `.fail()` lambda receives an `MTP::Error` object. Check `error.type()` against known error strings (often defined as constants or using `u"..."_q` literals).
-*   Directly construct the `MTPnamespace_MethodName(...)` object inside `request()`.
-*   Include `.handleFloodErrors()` before `.send()` for standard flood wait handling.
@@ -1,164 +0,0 @@
---
-description: For tasks requiring changing or adding user facing phrases and text parts.
-globs:
-alwaysApply: false
---
-# Telegram Desktop Localization
-
-## Coding Style Note
-
-**Use `auto`:** In the actual codebase, variable types are almost always deduced using `auto` (or `const auto`, `const auto &`) rather than being written out explicitly. Examples in this guide may use explicit types for clarity, but prefer `auto` in practice.
-
-```cpp
-// Prefer this:
-auto currentTitle = tr::lng_settings_title(tr::now);
-auto nameProducer = GetNameProducer(); // Returns rpl::producer<...>
-
-// Instead of this:
-QString currentTitle = tr::lng_settings_title(tr::now);
-rpl::producer<QString> nameProducer = GetNameProducer();
-```
-
-## String Resource File
-
-Base user-facing English strings are defined in the `lang.strings` file:
-
-`Telegram/Resources/langs/lang.strings`
-
-This file uses a key-value format with named placeholders:
-
-```
-"lng_settings_title" = "Settings";
-"lng_confirm_delete_item" = "Are you sure you want to delete {item_name}?";
-"lng_files_selected" = "{count} files selected"; // Simple count example (see Pluralization)
-```
-
-Placeholders are enclosed in curly braces, e.g., `{name}`, `{user}`. A special placeholder `{count}` is used for pluralization rules.
-
-### Pluralization
-
-For keys that depend on a number (using the `{count}` placeholder), English typically requires two forms: singular and plural. These are defined in `lang.strings` using `#one` and `#other` suffixes:
-
-```
-"lng_files_selected#one" = "{count} file selected";
-"lng_files_selected#other" = "{count} files selected";
-```
-
-While only `#one` and `#other` are defined in the base `lang.strings`, the code generation process creates C++ accessors for all six CLDR plural categories (`#zero`, `#one`, `#two`, `#few`, `#many`, `#other`) to support languages with more complex pluralization rules.
-
-## Translation Process
-
-While `lang.strings` provides the base English text and the keys, the actual translations are managed via Telegram's translations platform (translations.telegram.org) and loaded dynamically at runtime from the API. The keys from `lang.strings` (including the `#one`/`#other` variants) are used on the platform.
-
-## Code Generation
-
-A code generation tool processes `lang.strings` to create C++ structures and accessors within the `tr` namespace. These allow type-safe access to strings and handling of placeholders and pluralization. Generated keys typically follow the pattern `tr::lng_key_name`.
-
-## String Usage in Code
-
-Strings are accessed in C++ code using the generated objects within the `tr::` namespace. There are two main ways to use them: reactively (returning an `rpl::producer`) or immediately (returning the current value).
-
-### 1. Reactive Usage (rpl::producer)
-
-Calling a generated string function directly returns a reactive producer, typically `rpl::producer<QString>`. This producer automatically updates its value whenever the application language changes.
-
-```cpp
-// Key: "settings_title" = "Settings";
-auto titleProducer = tr::lng_settings_title(); // Type: rpl::producer<QString>
-
-// Key: "confirm_delete_item" = "Are you sure you want to delete {item_name}?";
-auto itemNameProducer = /* ... */; // Type: rpl::producer<QString>
-auto confirmationProducer = tr::lng_confirm_delete_item( // Type: rpl::producer<QString>
-    tr::now, // NOTE: tr::now is NOT passed here for reactive result
-    lt_item_name,
-    std::move(itemNameProducer)); // Placeholder producers should be moved
-```
-
-### 2. Immediate Usage (Current Value)
-
-Passing `tr::now` as the first argument retrieves the string's current value in the active language (typically as a `QString`).
-
-```cpp
-// Key: "settings_title" = "Settings";
-auto currentTitle = tr::lng_settings_title(tr::now); // Type: QString
-
-// Key: "confirm_delete_item" = "Are you sure you want to delete {item_name}?";
-const auto currentItemName = QString("My Document"); // Type: QString
-auto currentConfirmation = tr::lng_confirm_delete_item( // Type: QString
-    tr::now, // Pass tr::now for immediate value
-    lt_item_name, currentItemName); // Placeholder value is a direct QString (or convertible)
-```
-
-### 3. Placeholders (`{tag}`)
-
-Placeholders like `{item_name}` are replaced by providing arguments after `tr::now` (for immediate) or as the initial arguments (for reactive). A corresponding `lt_tag_name` constant is passed before the value.
-
-*   **Immediate:** Pass the direct value (e.g., `QString`, `int`).
-*   **Reactive:** Pass an `rpl::producer` of the corresponding type (e.g., `rpl::producer<QString>`). Remember to `std::move` the producer or use `rpl::duplicate` if you need to reuse the original producer afterwards.
-
-### 4. Pluralization (`{count}`)
-
-Keys using `{count}` require a numeric value for the `lt_count` placeholder. The correct plural form (`#zero`, `#one`, ..., `#other`) is automatically selected based on this value and the current language rules.
-
-*   **Immediate (`tr::now`):** Pass a `float64` or `int` (which is auto-converted to `float64`).
-    ```cpp
-    int count = 1;
-    auto filesText = tr::lng_files_selected(tr::now, lt_count, count); // Type: QString
-    count = 5;
-    filesText = tr::lng_files_selected(tr::now, lt_count, count); // Uses "files_selected#other"
-    ```
-
-*   **Reactive:** Pass an `rpl::producer<float64>`. Use the `tr::to_count()` helper to convert an `rpl::producer<int>` or wrap a single value.
-    ```cpp
-    // From an existing int producer:
-    auto countProducer = /* ... */; // Type: rpl::producer<int>
-    auto filesTextProducer = tr::lng_files_selected( // Type: rpl::producer<QString>
-        lt_count,
-        countProducer | tr::to_count()); // Use tr::to_count() for conversion
-
-    // From a single int value wrapped reactively:
-    int currentCount = 5;
-    auto filesTextProducerSingle = tr::lng_files_selected( // Type: rpl::producer<QString>
-        lt_count,
-        rpl::single(currentCount) | tr::to_count());
-        // Alternative for single values (less common): rpl::single(currentCount * 1.)
-    ```
-
-### 5. Custom Projectors
-
-An optional final argument can be a projector function (like `Ui::Text::Upper` or `Ui::Text::WithEntities`) to transform the output.
-
-*   If the projector returns `OutputType`, the string function returns `OutputType` (immediate) or `rpl::producer<OutputType>` (reactive).
-*   Placeholder values must match the projector's *input* requirements. For `Ui::Text::WithEntities`, placeholders expect `TextWithEntities` (immediate) or `rpl::producer<TextWithEntities>` (reactive).
-
-```cpp
-// Immediate with Ui::Text::WithEntities projector
-// Key: "user_posted_photo" = "{user} posted a photo";
-const auto userName = TextWithEntities{ /* ... */ }; // Type: TextWithEntities
-auto message = tr::lng_user_posted_photo( // Type: TextWithEntities
-    tr::now,
-    lt_user,
-    userName, // Must be TextWithEntities
-    Ui::Text::WithEntities); // Projector
-
-// Reactive with Ui::Text::WithEntities projector
-auto userNameProducer = /* ... */; // Type: rpl::producer<TextWithEntities>
-auto messageProducer = tr::lng_user_posted_photo( // Type: rpl::producer<TextWithEntities>
-    lt_user,
-    std::move(userNameProducer), // Move placeholder producers
-    Ui::Text::WithEntities); // Projector
-```
-
-## Key Summary
-
-*   Keys are defined in `Resources/langs/lang.strings` using `{tag}` placeholders.
-*   Plural keys use `{count}` and have `#one`/`#other` variants in `lang.strings`.
-*   Access keys via `tr::lng_key_name(...)` in C++.
-*   Call with `tr::now` as the first argument for the immediate `QString` (or projected type).
-*   Call without `tr::now` for the reactive `rpl::producer<QString>` (or projected type).
-*   Provide placeholder values (`lt_tag_name, value`) matching the usage (direct value for immediate, `rpl::producer` for reactive). Producers should typically be moved via `std::move`.
-*   For `{count}`:
-    *   Immediate: Pass `int` or `float64`.
-    *   Reactive: Pass `rpl::producer<float64>`, typically by converting an `int` producer using `| tr::to_count()`.
-*   Optional projector function as the last argument modifies the output type and required placeholder types.
-*   Actual translations are loaded at runtime from the API.
@@ -1,216 +0,0 @@
---
-description:
-globs:
-alwaysApply: true
---
-# RPL (Reactive Programming Library) Guide
-
-## Coding Style Note
-
-**Use `auto`:** In the actual codebase, variable types are almost always deduced using `auto` (or `const auto`, `const auto &`) rather than being written out explicitly. Examples in this guide may use explicit types for clarity, but prefer `auto` in practice.
-
-```cpp
-// Prefer this:
-auto intProducer = rpl::single(123);
-const auto &lifetime = existingLifetime;
-
-// Instead of this:
-rpl::producer<int> intProducer = rpl::single(123);
-const rpl::lifetime &lifetime = existingLifetime;
-
-// Sometimes needed if deduction is ambiguous or needs help:
-auto user = std::make_shared<UserData>();
-auto data = QByteArray::fromHex("...");
-```
-
-## Introduction
-
-RPL is the reactive programming library used in this project, residing in the `rpl::` namespace. It allows handling asynchronous streams of data over time.
-
-The core concept is the `rpl::producer`, which represents a stream of values that can be generated over a certain lifetime.
-
-## Producers: `rpl::producer<Type, Error = no_error>`
-
-The fundamental building block is `rpl::producer<Type, Error>`. It produces values of `Type` and can optionally signal an error of type `Error`. By default, `Error` is `rpl::no_error`, indicating that the producer does not explicitly handle error signaling through this mechanism.
-
-```cpp
-// A producer that emits integers.
-auto intProducer = /* ... */; // Type: rpl::producer<int>
-
-// A producer that emits strings and can potentially emit a CustomError.
-auto stringProducerWithError = /* ... */; // Type: rpl::producer<QString, CustomError>
-```
-
-Producers are typically lazy; they don't start emitting values until someone subscribes to them.
-
-## Lifetime Management: `rpl::lifetime`
-
-Reactive pipelines have a limited duration, managed by `rpl::lifetime`. An `rpl::lifetime` object essentially holds a collection of cleanup callbacks. When the lifetime ends (either explicitly destroyed or goes out of scope), these callbacks are executed, tearing down the associated pipeline and freeing resources.
-
-```cpp
-rpl::lifetime myLifetime;
-// ... later ...
-// myLifetime is destroyed, cleanup happens.
-
-// Or, pass a lifetime instance to manage a pipeline's duration.
-rpl::lifetime &parentLifetime = /* ... get lifetime from context ... */;
-```
-
-## Starting a Pipeline: `rpl::start_...`
-
-To consume values from a producer, you start a pipeline using one of the `rpl::start_...` methods. These methods subscribe to the producer and execute callbacks for the events they handle.
-
-The most common method is `rpl::start_with_next`:
-
-```cpp
-auto counter = /* ... */; // Type: rpl::producer<int>
-rpl::lifetime lifetime;
-
-// Counter is consumed here, use std::move if it's an l-value.
-std::move(
-    counter
-) | rpl::start_with_next([=]\(int nextValue) {
-    // Process the next integer value emitted by the producer.
-    qDebug() << "Received: " << nextValue;
-}, lifetime); // Pass the lifetime to manage the subscription.
-// Note: `counter` is now in a moved-from state and likely invalid.
-
-// If you need to start the same producer multiple times, duplicate it:
-// rpl::duplicate(counter) | rpl::start_with_next(...);
-
-// If you DON'T pass a lifetime to a start_... method:
-auto counter2 = /* ... */; // Type: rpl::producer<int>
-rpl::lifetime subscriptionLifetime = std::move(
-    counter2
-) | rpl::start_with_next([=]\(int nextValue) { /* ... */ });
-// The returned lifetime MUST be stored. If it's discarded immediately,
-// the subscription stops instantly.
-// `counter2` is also moved-from here.
-```
-
-Other variants allow handling errors (`_error`) and completion (`_done`):
-
-```cpp
-auto dataStream = /* ... */; // Type: rpl::producer<QString, Error>
-rpl::lifetime lifetime;
-
-// Assuming dataStream might be used again, we duplicate it for the first start.
-// If it's the only use, std::move(dataStream) would be preferred.
-rpl::duplicate(
-    dataStream
-) | rpl::start_with_error([=]\(Error &&error) {
-    // Handle the error signaled by the producer.
-    qDebug() << "Error: " << error.text();
-}, lifetime);
-
-// Using dataStream again, perhaps duplicated again or moved if last use.
-rpl::duplicate(
-    dataStream
-) | rpl::start_with_done([=] {
-    // Execute when the producer signals it's finished emitting values.
-    qDebug() << "Stream finished.";
-}, lifetime);
-
-// Last use of dataStream, so we move it.
-std::move(
-    dataStream
-) | rpl::start_with_next_error_done(
-    [=]\(QString &&value) { /* handle next value */ },
-    [=]\(Error &&error) { /* handle error */ },
-    [=] { /* handle done */ },
-    lifetime);
-```
-
-## Transforming Producers
-
-RPL provides functions to create new producers by transforming existing ones:
-
-*   `rpl::map`: Transforms each value emitted by a producer.
-    ```cpp
-    auto ints = /* ... */; // Type: rpl::producer<int>
-    // The pipe operator often handles the move implicitly for chained transformations.
-    auto strings = std::move(
-        ints // Explicit move is safer
-    ) | rpl::map([](int value) {
-        return QString::number(value * 2);
-    }); // Emits strings like "0", "2", "4", ...
-    ```
-
-*   `rpl::filter`: Emits only the values from a producer that satisfy a condition.
-    ```cpp
-    auto ints = /* ... */; // Type: rpl::producer<int>
-    auto evenInts = std::move(
-        ints // Explicit move is safer
-    ) | rpl::filter([](int value) {
-        return (value % 2 == 0);
-    }); // Emits only even numbers.
-    ```
-
-## Combining Producers
-
-You can combine multiple producers into one:
-
-*   `rpl::combine`: Combines the latest values from multiple producers whenever *any* of them emits a new value. Requires all producers to have emitted at least one value initially.
-    While it produces a `std::tuple`, subsequent operators like `map`, `filter`, and `start_with_next` can automatically unpack this tuple into separate lambda arguments.
-    ```cpp
-    auto countProducer = rpl::single(1); // Type: rpl::producer<int>
-    auto textProducer = rpl::single(u"hello"_q); // Type: rpl::producer<QString>
-    rpl::lifetime lifetime;
-
-    // rpl::combine takes producers by const-ref internally and duplicates,
-    // so move/duplicate is usually not strictly needed here unless you
-    // want to signal intent or manage the lifetime of p1/p2 explicitly.
-    auto combined = rpl::combine(
-        countProducer, // or rpl::duplicate(countProducer)
-        textProducer   // or rpl::duplicate(textProducer)
-    );
-
-    // Starting the combined producer consumes it.
-    // The lambda receives unpacked arguments, not the tuple itself.
-    std::move(
-        combined
-    ) | rpl::start_with_next([=]\(int count, const QString &text) {
-        // No need for std::get<0>(latest), etc.
-        qDebug() << "Combined: Count=" << count << ", Text=" << text;
-    }, lifetime);
-
-    // This also works with map, filter, etc.
-    std::move(
-        combined
-    ) | rpl::filter([=]\(int count, const QString &text) {
-        return count > 0 && !text.isEmpty();
-    }) | rpl::map([=]\(int count, const QString &text) {
-        return text.repeated(count);
-    }) | rpl::start_with_next([=]\(const QString &result) {
-        qDebug() << "Mapped & Filtered: " << result;
-    }, lifetime);
-    ```
-
-*   `rpl::merge`: Merges the output of multiple producers of the *same type* into a single producer. It emits a value whenever *any* of the source producers emits a value.
-    ```cpp
-    auto sourceA = /* ... */; // Type: rpl::producer<QString>
-    auto sourceB = /* ... */; // Type: rpl::producer<QString>
-
-    // rpl::merge also duplicates internally.
-    auto merged = rpl::merge(sourceA, sourceB);
-
-    // Starting the merged producer consumes it.
-    std::move(
-        merged
-    ) | rpl::start_with_next([=]\(QString &&value) {
-        // Receives values from either sourceA or sourceB as they arrive.
-        qDebug() << "Merged value: " << value;
-    }, lifetime);
-    ```
-
-## Key Concepts Summary
-
-*   Use `rpl::producer<Type, Error>` to represent streams of values.
-*   Manage subscription duration using `rpl::lifetime`.
-*   Pass `rpl::lifetime` to `rpl::start_...` methods.
-*   If `rpl::lifetime` is not passed, **store the returned lifetime** to keep the subscription active.
-*   Use operators like `| rpl::map`, `| rpl::filter` to transform streams.
-*   Use `rpl::combine` or `rpl::merge` to combine streams.
-*   When starting a chain (`std::move(producer) | rpl::map(...)`), explicitly move the initial producer.
-*   These functions typically duplicate their input producers internally.
-*   Starting a pipeline consumes the producer; use `
@@ -1,154 +0,0 @@
---
-description: For tasks requiring working with user facing UI components.
-globs:
-alwaysApply: false
---
-# Telegram Desktop UI Styling
-
-## Style Definition Files
-
-UI element styles (colors, fonts, paddings, margins, icons, etc.) are defined in `.style` files using a custom syntax. These files are located alongside the C++ source files they correspond to within specific UI component directories (e.g., `Telegram/SourceFiles/ui/chat/chat.style`).
-
-Definitions from other `.style` files can be included using the `using` directive at the top of the file:
-```style
-using "ui/basic.style";
-using "ui/widgets/widgets.style";
-```
-
-The central definition of named colors happens in `Telegram/SourceFiles/ui/colors.palette`. This file allows for theme generation and loading colors from various sources.
-
-### Syntax Overview
-
-1.  **Built-in Types:** The syntax recognizes several base types inferred from the value assigned:
-    *   `int`: Integer numbers (e.g., `lineHeight: 20;`)
-    *   `bool`: Boolean values (e.g., `useShadow: true;`)
-    *   `pixels`: Pixel values, ending with `px` (e.g., `borderWidth: 1px;`). Generated as `int` in C++.
-    *   `color`: Named colors defined in `colors.palette` (e.g., `background: windowBg;`)
-    *   `icon`: Defined inline using a specific syntax (see below). Generates `style::icon`.
-    *   `margins`: Four pixel values for margins or padding. Requires `margins(top, right, bottom, left)` syntax (e.g., `margin: margins(10px, 5px, 10px, 5px);` or `padding: margins(8px, 8px, 8px, 8px);`). Generates `style::margins` (an alias for `QMargins`).
-    *   `size`: Two pixel values for width and height (e.g., `iconSize: size(16px, 16px);`). Generates `style::size`.
-    *   `point`: Two pixel values for x and y coordinates (e.g., `textPos: point(5px, 2px);`). Generates `style::point`.
-    *   `align`: Alignment keywords (e.g., `textAlign: align(center);` or `iconAlign: align(left);`). Generates `style::align`.
-    *   `font`: Font definitions (e.g., `font: font(14px semibold);`). Generates `style::font`.
-    *   `double`: Floating point numbers (e.g., `disabledOpacity: 0.5;`)
-
-    *Note on Borders:* Borders are typically defined using multiple fields like `border: pixels;` (for width) and `borderFg: color;` (for color), rather than a single CSS-like property.
-
-2.  **Structure Definition:** You can define complex data structures directly within the `.style` file:
-    ```style
-    MyButtonStyle { // Defines a structure named 'MyButtonStyle'
-      textPadding: margins; // Field 'textPadding' expects margins type
-      icon: icon;         // Field 'icon' of type icon
-      height: pixels;     // Field 'height' of type pixels
-    }
-    ```
-    This generates a `struct MyButtonStyle { ... };` inside the `namespace style`. Fields will have corresponding C++ types (`style::margins`, `style::icon`, `int`).
-
-3.  **Variable Definition & Inheritance:** Variables are defined using `name: value;` or `groupName { ... }`. They can be of built-in types or custom structures. Structures can be initialized inline or inherit from existing variables.
-
-    **Icon Definition Syntax:** Icons are defined inline using the `icon{...}` syntax. The generator probes for `.svg` files or `.png` files (including `@2x`, `@3x` variants) based on the provided path stem.
-    ```style
-    // Single-part icon definition:
-    myIconSearch: icon{{ "gui/icons/search", iconColor }};
-    // Multi-part icon definition (layers drawn bottom-up):
-    myComplexIcon: icon{
-      { "gui/icons/background", iconBgColor },
-      { "gui/icons/foreground", iconFgColor }
-    };
-    // Icon with path modifiers (PNG only for flips, SVG only for size):
-    myFlippedIcon: icon{{ "gui/icons/arrow-flip_horizontal", arrowColor }};
-    myResizedIcon: icon{{ "gui/icons/logo-128x128", logoColor }}; // Forces 128x128 for SVG
-    ```
-
-    **Other Variable Examples:**
-    ```style
-    // Simple variables
-    buttonHeight: 30px;
-    activeButtonColor: buttonBgActive; // Named color from colors.palette
-
-    // Variable of a custom structure type, initialized inline
-    defaultButton: MyButtonStyle {
-      textPadding: margins(10px, 15px, 10px, 15px); // Use margins(...) syntax
-      icon: myIconSearch; // Assign the previously defined icon variable
-      height: buttonHeight; // Reference another variable
-    }
-
-    // Another variable inheriting from 'defaultButton' and overriding/adding fields
-    primaryButton: MyButtonStyle(defaultButton) {
-      icon: myComplexIcon; // Override icon with the multi-part one
-      backgroundColor: activeButtonColor; // Add a field not in MyButtonStyle definition
-    }
-
-    // Style group (often used for specific UI elements)
-    chatInput { // Example using separate border properties and explicit padding
-      border: 1px;                          // Border width
-      borderFg: defaultInputFieldBorder;    // Border color (named color)
-      padding: margins(5px, 10px, 5px, 10px); // Use margins(...) syntax for padding field
-      backgroundColor: defaultChatBg;       // Background color
-    }
-    ```
-
-## Code Generation
-
-A code generation tool processes these `.style` files and `colors.palette` to create C++ objects.
- The `using` directives resolve dependencies between `.style` files.
- Custom structure definitions (like `MyButtonStyle`) generate corresponding `struct MyButtonStyle { ... };` within the `namespace style`.
- Style variables/groups (like `defaultButton`, `primaryButton`, `chatInput`) are generated as objects/structs within the `st` namespace (e.g., `st::defaultButton`, `st::primaryButton`, `st::chatInput`). These generated structs contain members corresponding to the fields defined in the `.style` file.
- Color objects are generated into the `st` namespace as well, based on their names in `colors.palette` (e.g., `st::windowBg`, `st::buttonBgActive`).
- The generated header files for styles are placed in the `Telegram/SourceFiles/styles/` directory with a `style_` prefix (e.g., `styles/style_widgets.h` for `ui/widgets/widgets.style`). You include them like `#include "styles/style_widgets.h"`.
-
-Generated C++ types correspond to the `.style` types: `style::color`, `style::font`, `style::margins` (used for both `margin:` and `padding:` fields), `style::icon`, `style::size`, `style::point`, `style::align`, and `int` or `bool` for simple types.
-
-## Style Usage in Code
-
-Styles are applied in C++ code by referencing the generated `st::...` objects and their members.
-
-```cpp
-// Example: Including the generated style header
-#include "styles/style_widgets.h" // For styles defined in ui/widgets/widgets.style
-
-// ... inside some UI class code ...
-
-// Accessing members of a generated style struct
-int height = st::primaryButton.height; // Accessing the 'height' field (pixels -> int)
-const style::icon &icon = st::primaryButton.icon; // Accessing the 'icon' field (st::myComplexIcon)
-style::margins padding = st::primaryButton.textPadding; // Accessing 'textPadding'
-style::color bgColor = st::primaryButton.backgroundColor; // Accessing the color (st::activeButtonColor)
-
-// Applying styles (conceptual examples)
-myButton->setIcon(st::primaryButton.icon);
-myButton->setHeight(st::primaryButton.height);
-myButton->setPadding(st::primaryButton.textPadding);
-myButton->setBackgroundColor(st::primaryButton.backgroundColor);
-
-// Using styles directly in painting
-void MyWidget::paintEvent(QPaintEvent *e) {
-    Painter p(this);
-    p.fillRect(rect(), st::chatInput.backgroundColor); // Use color from chatInput style
-
-    // Border painting requires width and color
-    int borderWidth = st::chatInput.border; // Access border width (pixels -> int)
-    style::color borderColor = st::chatInput.borderFg; // Access border color
-    if (borderWidth > 0) {
-        p.setPen(QPen(borderColor, borderWidth));
-        // Adjust rect for pen width if needed before drawing
-        p.drawRect(rect().adjusted(borderWidth / 2, borderWidth / 2, -borderWidth / 2, -borderWidth / 2));
-    }
-
-    // Access padding (style::margins)
-    style::margins inputPadding = st::chatInput.padding;
-    // ... use inputPadding.top(), inputPadding.left() etc. for content layout ...
-}
-```
-
-**Key Points:**
-
-*   Styles are defined in `.style` files next to their corresponding C++ source files.
-*   `using "path/to/other.style";` includes definitions from other style files.
-*   Named colors are defined centrally in `ui/colors.palette`.
-*   `.style` syntax supports built-in types (like `pixels`, `color`, `margins`, `point`, `size`, `align`, `font`, `double`), custom structure definitions (`Name { field: type; ... }`), variable definitions (`name: value;`), and inheritance (`child: Name(parent) { ... }`).
-*   Values must match the expected type (e.g., fields declared as `margins` type, like `margin:` or `padding:`, require `margins(...)` syntax). Borders are typically set via separate `border: pixels;` and `borderFg: color;` fields.
-*   Icons are defined inline using `name: icon{{ "path_stem", color }};` or `name: icon{ { "path1", c1 }, ... };` syntax, with optional path modifiers.
-*   Code generation creates `struct` definitions in the `style` namespace for custom types and objects/structs in the `st` namespace for defined variables/groups.
-*   Generated headers are in `styles/` with a `style_` prefix and must be included.
-*   Access style properties via the generated `st::` objects (e.g., `st::primaryButton.height`, `st::chatInput.backgroundColor`).
@@ -49,7 +49,10 @@ body:
      label: Installation source
      multiple: false
      options:
-        - Binary from GitHub / official Telegram source
+        - Binary from GitHub / @AyuGramReleases channel
+        - Arch Linux (ayugram-desktop / ayugram-desktop-git)
+        - Arch Linux (ayugram-desktop-bin)
+        - flatpak by 0FL01
        - Other (unofficial) source
    validations:
      required: true
@@ -7,5 +7,5 @@ contact_links:
    url: https://bugs.telegram.org
    about: Any bug report or feature request not about Telegram Desktop.
  - name: Question
-    url: https://t.me/TelegramDesktopTalk
+    url: https://t.me/ayugramchat
    about: Ask a question.
@@ -1,6 +0,0 @@
-version: 2
-updates:
-  - package-ecosystem: "github-actions"
-    directory: "/"
-    schedule:
-      interval: "weekly"
@@ -0,0 +1,328 @@
+#!/usr/bin/env python3
+"""Convert changelog.txt to a static HTML page for GitHub Pages."""
+
+import re
+import shutil
+import sys
+import html
+from pathlib import Path
+
+MONTHS = [
+    "", "January", "February", "March", "April", "May", "June",
+    "July", "August", "September", "October", "November", "December",
+]
+
+VERSION_RE = re.compile(
+    r"^(\d+\.\d+(?:\.\d+)?)\s*"        # version number
+    r"(?:(alpha|beta|dev|stable)\s*)?"   # optional tag
+    r"\((\d{2})\.(\d{2})\.(\d{2,4})\)$" # date (DD.MM.YY or DD.MM.YYYY)
+)
+
+
+def parse_date(day: str, month: str, year: str) -> tuple[str, str, str]:
+    """Return (sort_key, raw_display, full_display) from DD, MM, YY strings."""
+    y = int(year)
+    if y < 100:
+        y += 2000
+    m = int(month)
+    d = int(day)
+    sort_key = f"{y:04d}-{m:02d}-{d:02d}"
+    raw_display = f"{day}.{month}.{year}"
+    full_display = f"{d} {MONTHS[m]} {y}"
+    return sort_key, raw_display, full_display
+
+
+def parse_changelog(text: str) -> list[dict]:
+    entries = []
+    current = None
+
+    for raw_line in text.splitlines():
+        line = raw_line.rstrip()
+        m = VERSION_RE.match(line)
+        if m:
+            if current:
+                entries.append(current)
+            version, tag, day, month, year = m.groups()
+            sort_key, raw_date, full_date = parse_date(day, month, year)
+            current = {
+                "version": version,
+                "tag": tag or "",
+                "date": raw_date,
+                "full_date": full_date,
+                "sort_key": sort_key,
+                "lines": [],
+            }
+        elif current is not None:
+            # Skip blank lines at the start
+            if not line and not current["lines"]:
+                continue
+            # Skip stray artifact lines
+            if line.strip() in ("),", "),"):
+                continue
+            current["lines"].append(line)
+
+    if current:
+        entries.append(current)
+
+    # Trim trailing blank lines from each entry
+    for entry in entries:
+        while entry["lines"] and not entry["lines"][-1]:
+            entry["lines"].pop()
+
+    return entries
+
+
+def render_entry(entry: dict) -> str:
+    version = html.escape(entry["version"])
+    tag = entry["tag"]
+    date = html.escape(entry["date"])
+    anchor = f"v{version}"
+
+    tag_html = ""
+    if tag and tag not in ("stable",):
+        tag_html = f' {html.escape(tag)}'
+
+    parts = [
+        f'<article class="entry" id="{anchor}">',
+        f'  <h2><a class="anchor" href="#{anchor}"></a>'
+        f'{version}{tag_html}'
+        f' <time>{date}</time></h2>',
+    ]
+
+    in_list = False
+    for line in entry["lines"]:
+        stripped = line.lstrip()
+        if stripped.startswith("- ") or stripped.startswith("\u2014 "):
+            # Bullet point (- or em dash)
+            if not in_list:
+                parts.append("  <ul>")
+                in_list = True
+            bullet_text = stripped[2:]
+            parts.append(f"    <li>{html.escape(bullet_text)}</li>")
+        else:
+            if in_list:
+                parts.append("  </ul>")
+                in_list = False
+            if stripped:
+                parts.append(f"  <p>{html.escape(stripped)}</p>")
+
+    if in_list:
+        parts.append("  </ul>")
+
+    parts.append("</article>")
+    return "\n".join(parts)
+
+
+def build_html(entries: list[dict]) -> str:
+    count = len(entries)
+    first_date = entries[-1]["full_date"] if entries else ""
+    latest_version = entries[0]["version"] if entries else ""
+
+    entries_html = "\n\n".join(render_entry(e) for e in entries)
+
+    return f"""<!DOCTYPE html>
+<html lang="en">
+<head>
+<meta charset="utf-8">
+<meta name="viewport" content="width=device-width, initial-scale=1">
+<title>Version history</title>
+<link rel="icon" type="image/png" sizes="32x32" href="icon32.png">
+<link rel="icon" type="image/png" sizes="16x16" href="icon16.png">
+<style>
+* {{ margin: 0; padding: 0; box-sizing: border-box; }}
+body {{
+  font: 12px / 18px "Lucida Grande", "Lucida Sans Unicode", Arial,
+    Helvetica, Verdana, sans-serif;
+  background: #fff;
+  color: #000;
+}}
+header {{
+  background: #1d98dc;
+  color: #fff;
+  padding: 2rem 1.5rem;
+  text-align: center;
+}}
+header h1 {{ font-size: 18px; font-weight: 700; }}
+header p {{ opacity: .85; margin-top: 4px; font-size: 12px; }}
+.container {{
+  max-width: 600px;
+  margin: 0 auto;
+  padding: 20px 15px;
+}}
+.search-box {{
+  position: sticky;
+  top: 0;
+  z-index: 10;
+  background: #fff;
+  padding: 8px 0 12px;
+}}
+.search-box input {{
+  width: 100%;
+  padding: 6px 10px;
+  font: 12px / 18px "Lucida Grande", "Lucida Sans Unicode", Arial,
+    Helvetica, Verdana, sans-serif;
+  border: 1px solid #ccc;
+  border-radius: 4px;
+  background: #fff;
+  color: #000;
+  outline: none;
+}}
+.search-box input:focus {{ border-color: #1d98dc; }}
+.entry {{
+  padding: 14px 0 4px;
+  scroll-margin-top: 48px;
+}}
+.entry h2 {{
+  font-size: 16px;
+  font-weight: 700;
+  line-height: 22px;
+  margin-bottom: 6px;
+  position: relative;
+}}
+.entry h2 .anchor {{
+  position: absolute;
+  left: -24px;
+  top: 0;
+  width: 24px;
+  height: 22px;
+  display: block;
+  opacity: 0;
+  transition: opacity .15s;
+  background: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' width='18' height='18' viewBox='0 0 16 16'%3E%3Cpath fill='%23168acd' d='M7.775 3.275a.75.75 0 0 0 1.06 1.06l1.25-1.25a2 2 0 1 1 2.83 2.83l-2.5 2.5a2 2 0 0 1-2.83 0 .75.75 0 0 0-1.06 1.06 3.5 3.5 0 0 0 4.95 0l2.5-2.5a3.5 3.5 0 0 0-4.95-4.95l-1.25 1.25zm-4.69 9.64a2 2 0 0 1 0-2.83l2.5-2.5a2 2 0 0 1 2.83 0 .75.75 0 0 0 1.06-1.06 3.5 3.5 0 0 0-4.95 0l-2.5 2.5a3.5 3.5 0 0 0 4.95 4.95l1.25-1.25a.75.75 0 0 0-1.06-1.06l-1.25 1.25a2 2 0 0 1-2.83 0z'/%3E%3C/svg%3E") 0 center / 18px no-repeat;
+  cursor: pointer;
+}}
+.entry h2:hover .anchor {{ opacity: .6; }}
+.entry h2 .anchor:hover {{ opacity: 1; }}
+.entry h2 time {{
+  font-size: 12px;
+  font-weight: 400;
+  color: #999;
+  margin-left: 6px;
+}}
+.entry ul {{
+  margin: 0 0 4px 8px;
+  padding: 0;
+  list-style: none;
+}}
+.entry li {{
+  padding: 2px 0 2px 16px;
+  position: relative;
+  color: #333;
+}}
+.entry li::before {{
+  content: "";
+  position: absolute;
+  left: 0;
+  top: 9px;
+  width: 6px;
+  height: 6px;
+  border-radius: 50%;
+  background: #009be1;
+}}
+.entry p {{
+  margin: 4px 0;
+  color: #555;
+  font-style: italic;
+}}
+.hidden {{ display: none; }}
+footer {{
+  text-align: center;
+  padding: 24px 15px;
+  font-size: 11px;
+  color: #999;
+}}
+footer a {{ color: #168acd; text-decoration: none; }}
+footer a:hover {{ text-decoration: underline; }}
+</style>
+</head>
+<body>
+
+<header>
+  <h1>Version history</h1>
+  <p>{count} releases since {first_date} &middot; latest: {latest_version}</p>
+</header>
+
+<div class="container">
+  <div class="search-box">
+    <input type="text" id="search" placeholder="Search versions and changes\u2026"
+           autocomplete="off" spellcheck="false">
+  </div>
+
+  <div id="entries">
+{entries_html}
+  </div>
+</div>
+
+<footer>
+  Auto-generated from
+  <a href="https://github.com/telegramdesktop/tdesktop/blob/dev/changelog.txt">changelog.txt</a>.
+  Source code is published under
+  <a href="https://github.com/telegramdesktop/tdesktop">GPL v3</a>.
+</footer>
+
+<script>
+(function() {{
+  var input = document.getElementById('search');
+  var entries = document.querySelectorAll('.entry');
+  var timer;
+  input.addEventListener('input', function() {{
+    clearTimeout(timer);
+    timer = setTimeout(function() {{
+      var q = input.value.toLowerCase().trim();
+      entries.forEach(function(el) {{
+        if (!q) {{
+          el.classList.remove('hidden');
+        }} else {{
+          el.classList.toggle('hidden', el.textContent.toLowerCase().indexOf(q) === -1);
+        }}
+      }});
+    }}, 150);
+  }});
+
+  // Anchor links: copy URL on click
+  document.addEventListener('click', function(e) {{
+    var anchor = e.target.closest('.anchor');
+    if (!anchor) return;
+    e.preventDefault();
+    var url = location.origin + location.pathname + anchor.getAttribute('href');
+    history.replaceState(null, '', anchor.getAttribute('href'));
+    if (navigator.clipboard) {{
+      navigator.clipboard.writeText(url);
+    }}
+  }});
+}})();
+</script>
+
+</body>
+</html>"""
+
+
+def main():
+    repo = Path(__file__).resolve().parent.parent.parent
+    src = repo / "changelog.txt"
+    if len(sys.argv) > 1:
+        src = Path(sys.argv[1])
+
+    out = repo / "docs" / "changelog" / "index.html"
+    if len(sys.argv) > 2:
+        out = Path(sys.argv[2])
+
+    text = src.read_text(encoding="utf-8")
+    entries = parse_changelog(text)
+    html_content = build_html(entries)
+
+    out.parent.mkdir(parents=True, exist_ok=True)
+    out.write_text(html_content, encoding="utf-8")
+
+    # Copy favicon files from resources
+    icons_src = repo / "Telegram" / "Resources" / "art"
+    for name in ("icon16.png", "icon32.png"):
+        icon = icons_src / name
+        if icon.exists():
+            shutil.copy2(icon, out.parent / name)
+
+    print(f"Generated {out} ({len(entries)} entries, {out.stat().st_size:,} bytes)")
+
+
+if __name__ == "__main__":
+    main()
@@ -54,5 +54,22 @@ stage
 .idea/
 cmake-build-debug/

+# Local configuration files
+settings.local.json
+*.local.json
+.env
+.env.local
+.env.*.local
+
+# Cursor IDE local settings (but keep .cursor/rules/)
+.cursor/*
+!.cursor/rules/
+
+# AI work folder (session-specific, not for version control)
+.ai
+
+# Generated changelog page (built by CI, deployed to GitHub Pages)
+/docs/changelog/
+
 # Project specific
 Telegram/SourceFiles/_other/packer_private.h
@@ -1,6 +1,3 @@
-[submodule "Telegram/ThirdParty/libtgvoip"]
-	path = Telegram/ThirdParty/libtgvoip
-	url = https://github.com/telegramdesktop/libtgvoip
 [submodule "Telegram/ThirdParty/GSL"]
 	path = Telegram/ThirdParty/GSL
 	url = https://github.com/Microsoft/GSL.git
@@ -76,9 +73,6 @@
 [submodule "Telegram/lib_webview"]
 	path = Telegram/lib_webview
 	url = https://github.com/desktop-app/lib_webview.git
-[submodule "Telegram/ThirdParty/jemalloc"]
-	path = Telegram/ThirdParty/jemalloc
-	url = https://github.com/jemalloc/jemalloc
 [submodule "Telegram/ThirdParty/dispatch"]
 	path = Telegram/ThirdParty/dispatch
 	url = https://github.com/apple/swift-corelibs-libdispatch
@@ -97,3 +91,9 @@
 [submodule "Telegram/ThirdParty/xdg-desktop-portal"]
 	path = Telegram/ThirdParty/xdg-desktop-portal
 	url = https://github.com/flatpak/xdg-desktop-portal.git
+[submodule "Telegram/lib_translate"]
+	path = Telegram/lib_translate
+	url = https://github.com/desktop-app/lib_translate
+[submodule "Telegram/lib_icu"]
+	path = Telegram/lib_icu
+	url = https://github.com/AyuGram/lib_icu.git
@@ -0,0 +1,344 @@
+# Agent Guide for Telegram Desktop
+
+This guide defines repository-wide instructions for coding agents working with the Telegram Desktop codebase.
+
+Avoid building the project.
+
+If you're asked to create a Pull Request, then clearly state in PR description that it was AI generated.
+
+# Development Guidelines
+
+## Coding Style
+
+**Do NOT write comments in code:**
+
+This is important! Do not write single-line comments that describe what the next line does - they are bloat. Comments are allowed ONLY to describe complex algorithms in detail, when the explanation requires at least 4-5 lines. Self-documenting code with clear variable and function names is preferred.
+
+```cpp
+// BAD - don't do this:
+// Get the user's name
+auto name = user->name();
+// Check if premium
+if (user->isPremium()) {
+
+// GOOD - no comments needed, code is self-explanatory:
+auto name = user->name();
+if (user->isPremium()) {
+
+// ACCEPTABLE - complex algorithm explanation (4+ lines):
+// The algorithm works by first collecting all visible messages
+// in the viewport, then calculating their intersection with
+// the clip rectangle. Messages are grouped by date headers,
+// and we need to account for sticky headers that may overlap
+// with the first message in each group.
+```
+
+**Style and formatting rules** are in `REVIEW.md` — see that file for empty-line-before-closing-brace, operator placement in multi-line expressions, if-with-initializer, and other mechanical style rules.
+
+**Use `auto` for type deduction:**
+
+Prefer `auto` (or `const auto`, `const auto &`) instead of explicit types:
+
+```cpp
+// Prefer this:
+auto currentTitle = tr::lng_settings_title(tr::now);
+auto nameProducer = GetNameProducer();
+
+// Instead of this:
+QString currentTitle = tr::lng_settings_title(tr::now);
+rpl::producer<QString> nameProducer = GetNameProducer();
+```
+
+## API Usage
+
+### API Schema Files
+
+API definitions use [TL Language](https://core.telegram.org/mtproto/TL):
+
+1. **`Telegram/SourceFiles/mtproto/scheme/mtproto.tl`** - MTProto protocol (encryption, auth, etc.)
+2. **`Telegram/SourceFiles/mtproto/scheme/api.tl`** - Telegram API (messages, users, chats, etc.)
+
+### Making API Requests
+
+Standard pattern using `api()`, generated `MTP...` types, and callbacks:
+
+```cpp
+api().request(MTPnamespace_MethodName(
+    MTP_flags(flags_value),
+    MTP_inputPeer(peer),
+    MTP_string(messageText),
+    MTP_long(randomId),
+    MTP_vector<MTPMessageEntity>()
+)).done([=](const MTPResponseType &result) {
+    // Handle successful response
+
+    // Multiple constructors - use .match() or check type:
+    result.match([&](const MTPDuser &data) {
+        // use data.vfirst_name().v
+    }, [&](const MTPDuserEmpty &data) {
+        // handle empty user
+    });
+
+    // Single constructor - use .data() shortcut:
+    const auto &data = result.data();
+    // use data.vmessages().v
+
+}).fail([=](const MTP::Error &error) {
+    // Handle API error
+    if (error.type() == u"FLOOD_WAIT_X"_q) {
+        // Handle flood wait
+    }
+}).handleFloodErrors().send();
+```
+
+**Key points:**
+- Always refer to `api.tl` for method signatures and return types
+- Use generated `MTP...` types for parameters (`MTP_int`, `MTP_string`, etc.)
+- For multiple constructors, use `.match()` or check `.type()` against `mtpc_` constants then call `.c_constructorName()`:
+  ```cpp
+  // Using match:
+  result.match([&](const MTPDuser &data) { ... }, [&](const MTPDuserEmpty &data) { ... });
+  // Or explicit type check:
+  if (result.type() == mtpc_user) {
+      const auto &data = result.c_user(); // asserts on type mismatch
+  }
+  ```
+- For single constructors, use `.data()` shortcut
+- Include `.handleFloodErrors()` before `.send()` in rare cases where you want special case flood error handling
+- Silently ignore HTTP 406 errors in UI: the server uses 406 to mean "show nothing to the user". Guard toasts with `MTP::IgnoreError(error)` or use `MTP::ShowErrorFallback(show, error)` (both in `mtproto/mtproto_response.h`) which shows `error.type()` as a toast unless the error should be ignored.
+
+## UI Styling
+
+### Style Files
+
+UI styles are defined in `.style` files using custom syntax:
+
+```style
+using "ui/basic.style";
+using "ui/widgets/widgets.style";
+
+MyButtonStyle {
+    textPadding: margins;
+    icon: icon;
+    height: pixels;
+}
+
+defaultButton: MyButtonStyle {
+    textPadding: margins(10px, 15px, 10px, 15px);
+    icon: icon{{ "gui/icons/search", iconColor }};
+    height: 30px;
+}
+
+primaryButton: MyButtonStyle(defaultButton) {
+    icon: icon{{ "gui/icons/check", iconColor }};
+}
+```
+
+**Built-in types:**
+- `int` - Integer numbers (e.g., `maxLines: 3;`)
+- `bool` - Boolean values (e.g., `useShadow: true;`)
+- `pixels` - Pixel values with `px` suffix (e.g., `10px`)
+- `color` - Named colors from `ui/colors.palette`
+- `icon` - Inline icon definition: `icon{{ "path/stem", color }}`
+- `margins` - Four values: `margins(top, right, bottom, left)`
+- `size` - Two values: `size(width, height)`
+- `point` - Two values: `point(x, y)`
+- `align` - Alignment: `align(center)`, `align(left)`
+- `font` - Font: `font(14px semibold)`
+- `double` - Floating point
+
+**Multi-part icons** (layers drawn bottom-up):
+```style
+myComplexIcon: icon{
+  { "gui/icons/background", iconBgColor },
+  { "gui/icons/foreground", iconFgColor }
+};
+```
+
+**Borders** are typically separate fields, not a single property:
+```style
+chatInput {
+  border: 1px;                       // width
+  borderFg: defaultInputFieldBorder; // color
+}
+```
+
+**Never hardcode sizes in code:**
+
+The app supports different interface scale options. Style `px` values are automatically scaled at runtime, but raw integer constants in code are not. Never use hardcoded numbers for margins, paddings, spacing, sizes, coordinates, or any other dimensional values. Always define them in `.style` files and reference via `st::`.
+
+```cpp
+// BAD - breaks at non-100% interface scale:
+p.drawText(10, 20, text);
+widget->setFixedHeight(48);
+auto margin = 8;
+auto iconSize = QSize(24, 24);
+
+// GOOD - define in .style file and reference:
+p.drawText(st::myWidgetTextLeft, st::myWidgetTextTop, text);
+widget->setFixedHeight(st::myWidgetHeight);
+auto margin = st::myWidgetMargin;
+auto iconSize = st::myWidgetIconSize;
+```
+
+**Duration constants**: Animation durations should NOT go in `.style` files, this is a legacy approach. Prefer `constexpr auto kName = crl::time(N)` in an anonymous namespace in the relevant `.cpp` file.
+
+### Usage in Code
+
+```cpp
+#include "styles/style_widgets.h"
+
+// Access style members
+int height = st::primaryButton.height;
+const style::icon &icon = st::primaryButton.icon;
+style::margins padding = st::primaryButton.textPadding;
+
+// Use in painting
+void MyWidget::paintEvent(QPaintEvent *e) {
+    Painter p(this);
+    p.fillRect(rect(), st::chatInput.backgroundColor);
+}
+```
+
+## Localization
+
+### String Definitions
+
+Strings are defined in `Telegram/Resources/langs/lang.strings`:
+
+```
+"lng_settings_title" = "Settings";
+"lng_confirm_delete_item" = "Are you sure you want to delete {item_name}?";
+"lng_files_selected#one" = "{count} file selected";
+"lng_files_selected#other" = "{count} files selected";
+```
+
+### Usage in Code
+
+**Immediate (current value):**
+
+```cpp
+auto currentTitle = tr::lng_settings_title(tr::now);
+
+auto currentConfirmation = tr::lng_confirm_delete_item(
+    tr::now,
+    lt_item_name, currentItemName);
+
+auto filesText = tr::lng_files_selected(tr::now, lt_count, count);
+```
+
+**Reactive (rpl::producer):**
+
+```cpp
+auto titleProducer = tr::lng_settings_title();
+
+auto confirmationProducer = tr::lng_confirm_delete_item(
+    lt_item_name,
+    std::move(itemNameProducer));
+
+auto filesTextProducer = tr::lng_files_selected(
+    lt_count,
+    countProducer | tr::to_count());
+```
+
+**Key points:**
+- Pass `tr::now` as first argument for immediate `QString`
+- Omit `tr::now` for reactive `rpl::producer<QString>`
+- Placeholders use `lt_tag_name, value` pattern
+- For `{count}`: immediate uses `int`, reactive uses `rpl::producer<float64>` with `| tr::to_count()`
+- Move producers with `std::move` when passing to placeholders
+- Rich text projectors — these `tr::` helpers serve double duty: as the **last argument** (projector) they set the return type to `TextWithEntities`, and as **placeholder values** they wrap individual substitutions in formatting. Always prefer them over `Ui::Text::Bold()`, `Ui::Text::RichLangValue`, etc. — see REVIEW.md for the full mapping.
+  - `tr::marked` — basic projection, converts `QString` to `TextWithEntities`
+  - `tr::rich` — interprets `**bold**`/`__italic__` markup in the string
+  - `tr::bold`, `tr::italic`, `tr::underline` — wrap text in that formatting
+  - `tr::link` — wrap as a clickable link
+  - `tr::url(u"https://..."_q)` — returns a projection that converts text to a link pointing to the given URL; can be passed to `rpl::map` or directly to a `tr::lng_...` call
+  ```cpp
+  // As last argument (projector):
+  auto title = tr::lng_export_progress_title(tr::now, tr::bold);
+  auto text = tr::lng_proxy_incorrect_secret(tr::now, tr::rich);
+  // As placeholder value wrapper + projector:
+  auto desc = tr::lng_some_key(
+      tr::now,
+      lt_name,
+      tr::bold(userName),
+      lt_group,
+      tr::bold(groupName),
+      tr::rich);
+  // Nested tr::lng as placeholder:
+  auto linked = tr::lng_settings_birthday_contacts(
+      lt_link,
+      tr::lng_settings_birthday_contacts_link(tr::url(link)),
+      tr::marked);
+  ```
+
+## RPL (Reactive Programming Library)
+
+### Core Concepts
+
+**Producers** represent streams of values over time:
+
+```cpp
+auto intProducer = rpl::single(123);  // Emits single value
+auto lifetime = rpl::lifetime();       // Manages subscription lifetime
+```
+
+### Starting Pipelines
+
+```cpp
+std::move(counter) | rpl::on_next([=](int value) {
+    qDebug() << "Received: " << value;
+}, lifetime);
+
+// Without lifetime parameter - MUST store returned lifetime:
+auto subscriptionLifetime = std::move(counter) | rpl::on_next([=](int value) {
+    // process value
+});
+```
+
+### Transforming Producers
+
+```cpp
+auto strings = std::move(ints) | rpl::map([](int value) {
+    return QString::number(value * 2);
+});
+
+auto evenInts = std::move(ints) | rpl::filter([](int value) {
+    return (value % 2 == 0);
+});
+```
+
+### Combining Producers
+
+**`rpl::combine`** - combines latest values (lambdas receive unpacked arguments):
+
+```cpp
+auto combined = rpl::combine(countProducer, textProducer);
+
+std::move(combined) | rpl::on_next([=](int count, const QString &text) {
+    qDebug() << "Count=" << count << ", Text=" << text;
+}, lifetime);
+```
+
+**`rpl::merge`** - merges producers of same type:
+
+```cpp
+auto merged = rpl::merge(sourceA, sourceB);
+
+std::move(merged) | rpl::on_next([=](QString &&value) {
+    qDebug() << "Merged value: " << value;
+}, lifetime);
+```
+
+**Other pipeline starters** — besides `rpl::on_next`, there are:
+- `rpl::on_error([=](Error &&e) { ... }, lifetime)` — handle errors
+- `rpl::on_done([=] { ... }, lifetime)` — handle stream completion
+- `rpl::on_next_error_done(nextCb, errorCb, doneCb, lifetime)` — handle all three
+
+The `Error` template parameter defaults to `rpl::no_error`: `rpl::producer<Type, Error = no_error>`.
+
+**Key points:**
+- Explicitly `std::move` producers when starting pipelines
+- Pass `rpl::lifetime` to `on_...` methods or store returned lifetime
+- Use `rpl::duplicate(producer)` to reuse a producer multiple times
+- Combined producers automatically unpack tuples in lambdas (works with `rpl::map`, `rpl::filter`, and `rpl::on_next`)
@@ -0,0 +1,3 @@
+# Claude Code Pointer
+
+Read `AGENTS.md` and treat it as the canonical repository-wide instructions.
@@ -12,19 +12,27 @@ include(cmake/validate_special_target.cmake)
 include(cmake/version.cmake)
 desktop_app_parse_version(Telegram/build/version)

-set(project_langs C CXX)
-if (APPLE)
-    list(APPEND project_langs OBJC OBJCXX)
-elseif (LINUX)
-    list(APPEND project_langs ASM)
+if (NOT DEFINED CMAKE_CONFIGURATION_TYPES)
+    set(configuration_types_init 1)
 endif()

 project(Telegram
-    LANGUAGES ${project_langs}
+    LANGUAGES C CXX
    VERSION ${desktop_app_version_cmake}
    DESCRIPTION "AyuGram Desktop"
    HOMEPAGE_URL "https://ayugram.one"
 )
+
+if (APPLE)
+    enable_language(OBJC OBJCXX)
+endif()
+
+if (configuration_types_init
+    AND CMAKE_CONFIGURATION_TYPES
+    AND NOT MinSizeRel IN_LIST CMAKE_CONFIGURATION_TYPES)
+    set(CMAKE_CONFIGURATION_TYPES "${CMAKE_CONFIGURATION_TYPES};MinSizeRel" CACHE STRING "" FORCE)
+endif()
+
 set_property(DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} PROPERTY VS_STARTUP_PROJECT Telegram)

 get_filename_component(third_party_loc "Telegram/ThirdParty" REALPATH)
@@ -39,9 +47,7 @@ include(cmake/variables.cmake)
 include(cmake/nice_target_sources.cmake)
 include(cmake/target_compile_options_if_exists.cmake)
 include(cmake/target_link_frameworks.cmake)
-include(cmake/target_link_optional_libraries.cmake)
 include(cmake/target_link_options_if_exists.cmake)
-include(cmake/target_link_static_libraries.cmake)
 include(cmake/init_target.cmake)
 include(cmake/generate_target.cmake)
 include(cmake/nuget.cmake)
@@ -1,7 +1,7 @@
 This file is part of Telegram Desktop,
 the official desktop application for the Telegram messaging service.

-Copyright (c) 2014-2025 The Telegram Desktop Authors.
+Copyright (c) 2014-2026 The Telegram Desktop Authors.

 Telegram Desktop is free software: you can redistribute it and/or modify
 it under the terms of the GNU General Public License as published by
@@ -11,6 +11,7 @@
 - Кастомизация шрифта
 - Режим Стримера
 - Локальный телеграм премиум
+- Переводчик
 - Превью медиа и быстрая реакция при сильном нажатии на тачпад (macOS)
 - Улучшенный вид

@@ -18,11 +19,18 @@

 <h3>
  <details>
-    <summary>Скриншоты настроек</summary>
-    <img src='.github/demos/demo1.png' width='268'>
-    <img src='.github/demos/demo2.png' width='268'>
-    <img src='.github/demos/demo3.png' width='268'>
-    <img src='.github/demos/demo4.png' width='268'>
+    <summary>Превью</summary>
+    <table>
+      <tr>
+        <td><img src='.github/demos/demo1.png' width='268' alt='Preferences'></td>
+        <td><img src='.github/demos/demo2.png' width='268' alt='AyuGram Options'></td>
+        <td><img src='.github/demos/demo3.png' width='268' alt='Message Filters'></td>
+      </tr>
+      <tr>
+        <td><img src='.github/demos/demo4.png' width='268' alt='Appearance'></td>
+        <td><img src='.github/demos/demo5.png' width='268' alt='Chats'></td>
+      </tr>
+    </table>
  </details>
 </h3>

@@ -30,7 +38,7 @@

 ### Windows

-#### Официальный вариант
+#### Официальная версия

 Вы можете скачать готовый бинарный файл со вкладки [Releases](https://github.com/AyuGram/AyuGramDesktop/releases) или из
 [Телеграм канала](https://t.me/AyuGramReleases).
@@ -55,19 +63,66 @@ scoop install ayugram

 ### macOS

+#### Официальная версия
+
 Вы можете скачать подписанный пакет со вкладки [Releases](https://github.com/AyuGram/AyuGramDesktop/releases).

+#### Homebrew
+
+```bash
+brew install --cask ayugram
+```
+
 ### Arch Linux

-Вы можете установить `ayugram-desktop` из [AUR](https://aur.archlinux.org/packages?O=0&K=ayugram).
+#### Из исходников (рекомендованный способ)
+
+Установите `ayugram-desktop` из [AUR](https://aur.archlinux.org/packages/ayugram-desktop).
+
+#### Готовые бинарники
+
+Установите `ayugram-desktop-bin` из [AUR](https://aur.archlinux.org/packages/ayugram-desktop-bin).
+
+Примечание: данный пакет собирается не нами.

 ### NixOS

-Попробуйте [этот репозиторий](https://github.com/ayugram-port/ayugram-desktop).
+#### Флейк (рекомендуется)
+
+Установите `ayugram-desktop` из [ndfined-crp/ayugram-desktop](https://github.com/ndfined-crp/ayugram-desktop)
+
+#### Nixpkgs
+
+Установите `ayugram-desktop` из [nixpkgs](https://search.nixos.org/packages?channel=unstable&show=ayugram-desktop)
+
+### ALT Linux
+
+[Sisyphus](https://packages.altlinux.org/en/sisyphus/srpms/ayugram-desktop/)
+
+### Gentoo Linux
+
+Инструкцию по установке можно найти в [этом репозитории](https://codeberg.org/OverLessArtem/ayugram-ebuild-gentoo).
+
+### Void Linux
+Инструкцию по установке можно найти в [этом репозитории](https://codeberg.org/OverLessArtem/ayugram-template-void)
+
+### EPM
+
+`epm play ayugram`
+
+### Fedora
+
+Из репозитория [RPM Fusion](https://admin.rpmfusion.org/pkgdb/package/free/ayugram-desktop/).
+
+```bash
+dnf install ayugram-desktop
+```

 ### Любой другой Линукс дистрибутив

-Следуйте [официальному руководству](https://github.com/AyuGram/AyuGramDesktop/blob/dev/docs/building-linux.md).
+Flatpak: https://github.com/0FL01/AyuGramDesktop-flatpak
+
+Или следуйте [официальному руководству](https://github.com/AyuGram/AyuGramDesktop/blob/dev/docs/building-linux.md).

 ### Примечания для Windows

@@ -101,3 +156,7 @@ scoop install ayugram
 ### Иконки

 - [Solar Icon Set](https://www.figma.com/community/file/1166831539721848736)
+
+### Боты
+
+- [TelegramDB](https://t.me/tgdatabase) для получения юзернейма по ID (до закрытия бесплатной версии 2 апреля 2026)
@@ -12,6 +12,7 @@
 - Font customization
 - Streamer mode
 - Local Telegram Premium
+- Translator
 - Media preview & quick reaction on force click (macOS)
 - Enhanced appearance

@@ -19,11 +20,18 @@ And many more. Check out our [Documentation](https://docs.ayugram.one/desktop/).

 <h3>
  <details>
-    <summary>Preferences screenshots</summary>
-    <img src='.github/demos/demo1.png' width='268'>
-    <img src='.github/demos/demo2.png' width='268'>
-    <img src='.github/demos/demo3.png' width='268'>
-    <img src='.github/demos/demo4.png' width='268'>
+    <summary>Preview</summary>
+    <table>
+      <tr>
+        <td><img src='.github/demos/demo1.png' width='268' alt='Preferences'></td>
+        <td><img src='.github/demos/demo2.png' width='268' alt='AyuGram Options'></td>
+        <td><img src='.github/demos/demo3.png' width='268' alt='Message Filters'></td>
+      </tr>
+      <tr>
+        <td><img src='.github/demos/demo4.png' width='268' alt='Appearance'></td>
+        <td><img src='.github/demos/demo5.png' width='268' alt='Chats'></td>
+      </tr>
+    </table>
  </details>
 </h3>

@@ -56,19 +64,66 @@ build by yourself.

 ### macOS

+#### Official
+
 You can download prebuilt macOS package from [Releases tab](https://github.com/AyuGram/AyuGramDesktop/releases).

+#### Homebrew
+
+```bash
+brew install --cask ayugram
+```
+
 ### Arch Linux

-You can install `ayugram-desktop` from [AUR](https://aur.archlinux.org/packages?O=0&K=ayugram).
+#### From source (recommended)
+
+Install `ayugram-desktop` from [AUR](https://aur.archlinux.org/packages/ayugram-desktop).
+
+#### Prebuilt binaries
+
+Install `ayugram-desktop-bin` from [AUR](https://aur.archlinux.org/packages/ayugram-desktop-bin).
+
+Note: these binaries aren't officially maintained by us.

 ### NixOS

-See [this repository](https://github.com/ayugram-port/ayugram-desktop) for installation manual.
+#### Flake (recommended)
+
+Install `ayugram-desktop` from [ndfined-crp/ayugram-desktop](https://github.com/ndfined-crp/ayugram-desktop)
+
+#### Nixpkgs
+
+Install `ayugram-desktop` from [nixpkgs](https://search.nixos.org/packages?channel=unstable&show=ayugram-desktop)
+
+### ALT Linux
+
+[Sisyphus](https://packages.altlinux.org/en/sisyphus/srpms/ayugram-desktop/)
+
+### Gentoo Linux
+
+See [this repository](https://codeberg.org/OverLessArtem/ayugram-ebuild-gentoo) for installation manual.
+
+### Void Linux
+See [this repository](https://codeberg.org/OverLessArtem/ayugram-template-void) for installation manual.
+
+### EPM
+
+`epm play ayugram`
+
+### Fedora
+
+From [RPM Fusion](https://admin.rpmfusion.org/pkgdb/package/free/ayugram-desktop/) repository.
+
+```bash
+dnf install ayugram-desktop
+```

 ### Any other Linux distro

-Follow the [official guide](https://github.com/AyuGram/AyuGramDesktop/blob/dev/docs/building-linux.md).
+Flatpak: https://github.com/0FL01/AyuGramDesktop-flatpak
+
+Or follow the [official guide](https://github.com/AyuGram/AyuGramDesktop/blob/dev/docs/building-linux.md).

 ### Remarks for Windows

@@ -98,7 +153,12 @@ Enjoy using **AyuGram**? Consider sending us a tip!
 - [JSON for Modern C++](https://github.com/nlohmann/json)
 - [SQLite](https://github.com/sqlite/sqlite)
 - [sqlite_orm](https://github.com/fnc12/sqlite_orm)
+- [androidx sources](https://github.com/androidx/androidx)

 ### Icons

 - [Solar Icon Set](https://www.figma.com/community/file/1166831539721848736)
+
+### Bots
+
+- [TelegramDB](https://t.me/tgdatabase) for username lookup by ID (until closing free inline mode at 2 April 2026)
@@ -0,0 +1,514 @@
+# Code Review Style Guide
+
+This file contains style and formatting rules that the review subagent must check and fix. These are mechanical issues that should always be caught during code review.
+
+## Empty line before closing brace
+
+Always add an empty line before the closing brace of a **class** (which has one or more sections like `public:` / `private:`). Plain **structs** with just data members do NOT get a trailing empty line — they are compact: `struct Foo { data lines; };`.
+
+```cpp
+// BAD:
+class MyClass {
+public:
+    void foo();
+
+private:
+    int _value = 0;
+};
+
+// GOOD:
+class MyClass {
+public:
+    void foo();
+
+private:
+    int _value = 0;
+
+};
+```
+
+## Multi-line expressions — operators at the start of continuation lines
+
+When splitting an expression across multiple lines, place operators (like `&&`, `||`, `;`, `+`, etc.) at the **beginning** of continuation lines, not at the end of the previous line. This makes it immediately obvious from the left edge whether a line is a continuation or new code.
+
+```cpp
+// BAD - continuation looks like scope code:
+if (const auto &lottie = animation->lottie;
+	lottie && lottie->valid() && lottie->framesCount() > 1) {
+	lottie->animate([=] {
+
+// GOOD - semicolon at start signals continuation:
+if (const auto &lottie = animation->lottie
+	; lottie && lottie->valid() && lottie->framesCount() > 1) {
+	lottie->animate([=] {
+
+// BAD - trailing && makes next line look like independent code:
+if (veryLongExpression() &&
+	anotherLongExpression() &&
+	anotherOne()) {
+	doSomething();
+
+// GOOD - leading && clearly marks continuation:
+if (veryLongExpression()
+	&& anotherLongExpression()
+	&& anotherOne()) {
+	doSomething();
+```
+
+## Minimize type checks — prefer direct cast over is + as
+
+Don't check a type and then cast — just cast and check for null. `asUser()` already returns `nullptr` when the peer is not a user, so calling `isUser()` first is redundant. The same applies to `asChannel()`, `asChat()`, etc.
+
+```cpp
+// BAD - redundant isUser() check, then asUser():
+if (peer && peer->isUser()) {
+	peer->asUser()->setNoForwardFlags(
+
+// GOOD - just cast and null-check:
+if (const auto user = peer->asUser()) {
+	user->setNoForwardFlags(
+```
+
+When you need a specific subtype, look up the specific subtype directly instead of loading a generic type and then casting:
+
+```cpp
+// BAD - loads generic peer, then casts:
+if (const auto peer = session().data().peerLoaded(peerId)
+	; peer && peer->isUser()) {
+	peer->asUser()->setNoForwardFlags(
+
+// GOOD - look up the specific subtype directly:
+const auto userId = peerToUser(peerId);
+if (const auto user = session().data().userLoaded(userId)) {
+	user->setNoForwardFlags(
+```
+
+Avoid C++17 `if` with initializer (`;` inside the condition) when the code can be written more clearly with simple nested `if` statements or by extracting the value beforehand:
+
+```cpp
+// BAD - complex if-with-initializer:
+if (const auto peer = session().data().peerLoaded(peerId)
+	; peer && peer->isUser()) {
+
+// GOOD - simple nested ifs when direct lookup isn't available:
+if (const auto peer = session().data().peerLoaded(peerId)) {
+	if (const auto user = peer->asUser()) {
+
+## Always initialize variables of basic types
+
+Never leave variables of basic types (`int`, `float`, `bool`, pointers, etc.) uninitialized. Custom types with constructors are fine — they initialize themselves. But for any basic type, always provide a default value (`= 0`, `= false`, `= nullptr`, etc.). This applies especially to class fields, where uninitialized members are a persistent source of bugs.
+
+The only exception is performance-critical hot paths where you can prove no read-from-uninitialized-memory occurs. For class fields there is no such exception — always initialize.
+
+```cpp
+// BAD:
+int _bulletLeft;
+int _bulletTop;
+bool _expanded;
+SomeType *_pointer;
+
+// GOOD:
+int _bulletLeft = 0;
+int _bulletTop = 0;
+bool _expanded = false;
+SomeType *_pointer = nullptr;
+```
+
+## Use tr:: projections for TextWithEntities
+
+Inside `tr::lng_...()` calls, always use the `tr::` projection helpers instead of their `Ui::Text::` equivalents. The `tr::` helpers are shorter and work uniformly as both placeholder wrappers and final projectors.
+
+| Instead of | Use |
+|---|---|
+| `Ui::Text::Bold(x)` | `tr::bold(x)` |
+| `Ui::Text::Italic(x)` | `tr::italic(x)` |
+| `Ui::Text::RichLangValue` | `tr::rich` |
+| `Ui::Text::WithEntities` | `tr::marked` |
+
+```cpp
+// BAD - verbose Ui::Text:: functions:
+tr::lng_some_key(
+    tr::now,
+    lt_name,
+    Ui::Text::Bold(name),
+    lt_group,
+    Ui::Text::Bold(group),
+    Ui::Text::RichLangValue)
+
+// GOOD - concise tr:: helpers:
+tr::lng_some_key(
+    tr::now,
+    lt_name,
+    tr::bold(name),
+    lt_group,
+    tr::bold(group),
+    tr::rich)
+```
+
+Also use `tr::marked()` as the standard way to create `TextWithEntities` — not just as a projector:
+
+```cpp
+// BAD - verbose constructor:
+auto text = TextWithEntities();
+auto text = TextWithEntities{ u"hello"_q };
+auto text = TextWithEntities().append(u"hello"_q);
+
+// GOOD - concise:
+auto text = tr::marked();
+auto text = tr::marked(u"hello"_q);
+```
+
+## Multi-line calls — one argument per line
+
+When a function call doesn't fit on one line, put each argument on its own line. Don't group "logical pairs" on the same line — it creates inconsistent line lengths and makes diffs noisier.
+
+```cpp
+// BAD - pairs of arguments sharing lines:
+tr::lng_some_key(
+    tr::now,
+    lt_name, tr::bold(name),
+    lt_group, tr::bold(group),
+    tr::rich)
+
+// GOOD - one argument per line:
+tr::lng_some_key(
+    tr::now,
+    lt_name,
+    tr::bold(name),
+    lt_group,
+    tr::bold(group),
+    tr::rich)
+
+// Single-line is fine when everything fits:
+auto text = tr::lng_settings_title(tr::now);
+```
+
+## std::optional access — avoid value()
+
+Do not call `std::optional::value()` because it throws an exception that is not available on older macOS targets. Use `has_value()`, `value_or()`, `operator bool()`, or `operator*` instead.
+
+## Sort includes alphabetically, nested folders first
+
+After the file's own header, sort `#include` directives alphabetically with two special rules:
+
+1. **Nested folders before files** in the same directory — like Finder / File Explorer (folders first, then files). E.g. `ui/controls/button.h` sorts before `ui/abstract_button.h`.
+2. **Style includes (`styles/style_*.h`) always go last**, separated from the rest.
+
+```cpp
+// BAD - arbitrary order, style mixed in:
+#include "media/audio/media_audio.h"
+#include "styles/style_media_player.h"
+#include "data/data_document.h"
+#include "apiwrap.h"
+
+// GOOD - alphabetical, folders first, styles last:
+#include "apiwrap.h"
+#include "data/data_document.h"
+#include "media/audio/media_audio.h"
+
+#include "styles/style_media_player.h"
+```
+
+## Use C++17 nested namespace syntax
+
+Use `namespace A::B {` instead of nesting `namespace A { namespace B {`. The closing comment mirrors the opening: `} // namespace A::B`.
+
+```cpp
+// BAD - old-style nesting:
+namespace Media {
+namespace Player {
+...
+} // namespace Player
+} // namespace Media
+
+// GOOD - C++17 nested:
+namespace Media::Player {
+...
+} // namespace Media::Player
+```
+
+## Merge consecutive branches with identical bodies
+
+When two or more consecutive `if` / `else if` branches execute the same code, combine their conditions into a single branch.
+
+```cpp
+// BAD - duplicated body:
+if (!document) {
+    finalize();
+    return;
+}
+if (!document->isSong()) {
+    finalize();
+    return;
+}
+
+// GOOD - combined:
+if (!document || !document->isSong()) {
+    finalize();
+    return;
+}
+```
+
+## Use base::take for read-and-reset
+
+When you need to read a variable's current value and reset it in one step, use `base::take(var)` instead of manually copying and clearing. `base::take` returns the old value and resets the variable to its default-constructed state.
+
+```cpp
+// BAD - manual read + reset:
+if (_playing) {
+    _listenedMs += crl::now() - _playStartedAt;
+    _playing = false;
+}
+
+// GOOD:
+if (base::take(_playing)) {
+    _listenedMs += crl::now() - _playStartedAt;
+}
+
+// BAD - copy fields then clear them one by one:
+const auto document = _document;
+const auto contextId = _contextId;
+_document = nullptr;
+_listenedMs = 0;
+if (!document) {
+    return;
+}
+
+// GOOD - take everything upfront, then validate:
+const auto document = base::take(_document);
+const auto contextId = base::take(_contextId);
+const auto duration = static_cast<int>(base::take(_listenedMs) / 1000);
+if (!document || duration <= 0) {
+    return;
+}
+```
+
+## Don't wrap tr:: lang keys in rpl::single
+
+`tr::lng_*()` (without `tr::now`) already returns an `rpl::producer`. Wrapping a snapshot in `rpl::single()` defeats live language switching — the value is captured once and never updates. Just call the lang key without `tr::now`.
+
+```cpp
+// BAD - frozen snapshot, won't update on language change:
+rpl::single(tr::lng_ai_compose_title(tr::now))
+
+// GOOD - live producer that updates automatically:
+tr::lng_ai_compose_title()
+```
+
+## Extract method definitions from local classes
+
+When defining local classes (e.g. in anonymous namespaces), keep the class body compact — only declarations. Put all method definitions **after** all class definitions. This avoids unnecessary nesting inside the class body and keeps methods at the same indentation level as free functions.
+
+```cpp
+// BAD - methods defined inline, adding a nesting level:
+class MyWidget final : public Ui::RpWidget {
+public:
+    MyWidget(QWidget *parent)
+    : RpWidget(parent) {
+        // ... 20 lines of setup
+    }
+
+    void setActive(bool active) {
+        _active = active;
+        update();
+    }
+
+protected:
+    void paintEvent(QPaintEvent *e) override {
+        // ... 30 lines of painting
+    }
+
+private:
+    bool _active = false;
+
+};
+
+// GOOD - class is a compact declaration, methods defined after:
+class MyWidget final : public Ui::RpWidget {
+public:
+    MyWidget(QWidget *parent, QString label);
+
+    void setActive(bool active);
+
+protected:
+    void paintEvent(QPaintEvent *e) override;
+
+private:
+    bool _active = false;
+
+};
+
+MyWidget::MyWidget(QWidget *parent, QString label)
+: RpWidget(parent) {
+    // ... 20 lines of setup
+}
+
+void MyWidget::setActive(bool active) {
+    _active = active;
+    update();
+}
+
+void MyWidget::paintEvent(QPaintEvent *e) {
+    // ... 30 lines of painting
+}
+```
+
+When there are multiple local classes, put **all class definitions first**, then **all method definitions** after. This keeps the declarations readable as an overview.
+
+## Use RAII for resource cleanup
+
+When working with raw resources (Win32 HANDLEs, file descriptors, COM objects), use `gsl::finally` or a dedicated RAII wrapper for cleanup instead of calling release functions manually. Manual cleanup breaks when early returns are added later.
+
+```cpp
+// BAD - manual cleanup, fragile with early returns:
+const auto snapshot = CreateToolhelp32Snapshot(...);
+if (snapshot != INVALID_HANDLE_VALUE) {
+	// ... logic that might grow early returns ...
+	CloseHandle(snapshot);
+}
+
+// GOOD - RAII guard, cleanup runs on any exit path:
+const auto snapshot = CreateToolhelp32Snapshot(...);
+if (snapshot == INVALID_HANDLE_VALUE) {
+	return;
+}
+const auto guard = gsl::finally([&] {
+	CloseHandle(snapshot);
+});
+// ... logic, early returns are safe ...
+```
+
+## Extract substantial logic from lambdas
+
+When a lambda grows beyond a few lines of self-contained logic, extract it into a named function (free function in anonymous namespace, or a private method). Lambdas should primarily be glue — captures, dispatch, short transforms. This applies when the lambda's captures are minimal and can easily become function parameters. When a lambda captures many variables from its surrounding context, it may be cleaner to keep it inline.
+
+```cpp
+// BAD - substantial logic buried in a lambda:
+crl::async([=] {
+	auto found = false;
+	auto pe = PROCESSENTRY32();
+	pe.dwSize = sizeof(PROCESSENTRY32);
+	const auto snapshot = CreateToolhelp32Snapshot(...);
+	if (snapshot != INVALID_HANDLE_VALUE) {
+		for (...) {
+			if (/* match */) {
+				found = true;
+				break;
+			}
+		}
+		CloseHandle(snapshot);
+	}
+	crl::on_main(weak, [=] { handle(found); });
+});
+
+// GOOD - logic extracted, lambda is just glue:
+crl::async([=] {
+	const auto found = FindRunningReader();
+	crl::on_main(weak, [=] { handle(found); });
+});
+```
+
+## Data-driven matching over chained conditions
+
+When comparing a value against multiple known constants, store them in a collection and loop instead of chaining `||` conditions. Easier to extend, less repetition, and reads as data rather than logic.
+
+```cpp
+// BAD - repetitive chain, hard to extend:
+if (_wcsicmp(name, L"Narrator.exe") == 0
+	|| _wcsicmp(name, L"nvda.exe") == 0
+	|| _wcsicmp(name, L"jfw.exe") == 0
+	|| _wcsicmp(name, L"Zt.exe") == 0) {
+
+// GOOD - data-driven, easy to extend:
+const auto list = std::array{
+	L"Narrator.exe",
+	L"nvda.exe",
+	L"jfw.exe",
+	L"Zt.exe",
+};
+for (const auto &entry : list) {
+	if (_wcsicmp(name, entry) == 0) {
+		return true;
+	}
+}
+```
+
+## Use !isHidden() for logic checks, not isVisible()
+
+When you call `show()` / `hide()` / `setVisible()` on a widget and later branch on that state, always check `!isHidden()` (the widget's own flag) — never `isVisible()`. `isVisible()` returns `true` only when the widget **and every ancestor** are visible, so it silently returns `false` during parent show-animations, before the parent is laid out, etc. `isHidden()` reflects exactly the flag you set.
+
+```cpp
+// BAD — breaks when parent is still animating / not yet shown:
+child->setVisible(true);
+// ... later, in resizeGetHeight or similar:
+if (child->isVisible()) {   // false if parent isn't visible yet!
+    child->moveToRight(x, y, w);
+}
+
+// GOOD — checks the widget's own state:
+if (!child->isHidden()) {
+    child->moveToRight(x, y, w);
+}
+```
+
+The same applies to any logic that depends on a previous `show()`/`hide()` call: skip blocks, layout branches, opacity decisions, etc.
+
+## Consolidate make_state calls into a single State struct
+
+Every `make_state` is a separate heap allocation. When a function needs multiple pieces of lambda-captured mutable state, define a local `struct State` with all fields and call `make_state<State>()` once, then capture the resulting pointer everywhere.
+
+```cpp
+// BAD - two allocations:
+const auto shown = lifetime.make_state<bool>(false);
+const auto count = lifetime.make_state<int>(0);
+
+// GOOD - one allocation:
+struct State {
+	bool shown = false;
+	int count = 0;
+};
+const auto state = lifetime.make_state<State>();
+```
+
+## Use trailing return type when the return type doesn't fit on one line
+
+When a function's return type is long enough that the declaration would need a line break between the return type and the function name, use trailing return type syntax (`auto ... -> Type`) to keep the function name on the opening line.
+
+```cpp
+// BAD - return type orphaned on its own line:
+not_null<HistoryView::Controls::ComposeAiButton*>
+SetupCaptionAiButton(SetupCaptionAiButtonArgs &&args);
+
+// GOOD - trailing return type keeps name visible:
+auto SetupCaptionAiButton(SetupCaptionAiButtonArgs &&args)
+-> not_null<HistoryView::Controls::ComposeAiButton*>;
+```
+
+## Mind data structure sizes and alignment
+
+When adding fields to a class or struct, consider the memory layout. A standalone `bool` between two pointer-sized fields wastes 7 bytes to alignment padding. Review new fields for packing opportunities:
+
+- If the struct already has bitfields, pack new boolean flags as `: 1` members rather than standalone `bool`.
+- If alignment leaves a gap (e.g., an `int` followed by a pointer), consider whether a new small field can fill it.
+- For classes instantiated in large quantities (per-message, per-element, per-row), every wasted byte is multiplied thousands of times.
+
+```cpp
+// BAD - standalone bool adds 8 bytes (1 + 7 padding) before the next pointer:
+mutable bool _myFlag = false;
+mutable std::unique_ptr<Foo> _foo;
+
+// GOOD - packed into existing bitfield group, no extra bytes:
+mutable uint32 _myFlag : 1 = 0;
+```
+
+## Static member functions use PascalCase
+
+Non-static member functions use camelCase (`startBatch`, `finalize`). Static member functions use PascalCase (`ShouldTrack`, `Parse`, `Create`), matching the convention for free functions.
+
+```cpp
+// BAD - camelCase for static method:
+[[nodiscard]] static bool shouldTrack(not_null<HistoryItem*> item);
+
+// GOOD - PascalCase for static method:
+[[nodiscard]] static bool ShouldTrack(not_null<HistoryItem*> item);
+```
@@ -0,0 +1,20 @@
+<svg width="1200" height="1200" viewBox="0 0 1200 1200" fill="none" xmlns="http://www.w3.org/2000/svg">
+<g clip-path="url(#clip0_1177_97)">
+<rect width="1200" height="1200" rx="600" fill="#9570FF"/>
+<g opacity="0.07">
+<path d="M806.896 -279.064C785.598 -313.026 733.108 -291.661 741.582 -252.479L1066.32 1248.94C1069.88 1265.41 1084.45 1277.16 1101.31 1277.16H1718.15C1746.29 1277.16 1763.42 1246.19 1748.47 1222.35L806.896 -279.064Z" fill="white"/>
+<path d="M669.079 1606.13C669.079 1640.4 712.592 1655.08 733.354 1627.82L935.184 1362.81C941.526 1354.48 943.905 1343.8 941.696 1333.57L739.866 399.014C730.809 357.077 669.079 363.667 669.079 406.57L669.079 1606.13Z" fill="white"/>
+<path d="M392.104 -279.064C413.403 -313.026 465.892 -291.661 457.418 -252.479L132.68 1248.94C129.117 1265.41 114.546 1277.16 97.692 1277.16H-519.146C-547.286 1277.16 -564.423 1246.19 -549.473 1222.35L392.104 -279.064Z" fill="white"/>
+<path d="M529.921 1606.13C529.921 1640.4 486.408 1655.08 465.646 1627.82L263.816 1362.81C257.474 1354.48 255.095 1343.8 257.304 1333.57L459.134 399.014C468.191 357.077 529.921 363.667 529.921 406.57V1606.13Z" fill="white"/>
+</g>
+<path d="M672.345 264.951C664.864 253.017 646.428 260.525 649.404 274.293L763.463 801.88C764.715 807.668 769.833 811.799 775.752 811.799H992.407C1002.29 811.799 1008.31 800.915 1003.06 792.538L672.345 264.951Z" fill="white"/>
+<path d="M623.939 927.397C623.939 939.438 639.222 944.597 646.514 935.018L717.404 841.895C719.631 838.969 720.467 835.214 719.691 831.618L648.801 503.223C645.62 488.487 623.939 490.802 623.939 505.878L623.939 927.397Z" fill="white"/>
+<path d="M526.655 264.951C534.136 253.017 552.572 260.525 549.596 274.293L435.537 801.88C434.285 807.668 429.167 811.799 423.248 811.799H206.593C196.709 811.799 190.69 800.915 195.941 792.538L526.655 264.951Z" fill="white"/>
+<path d="M575.061 927.397C575.061 939.438 559.778 944.597 552.486 935.018L481.596 841.895C479.369 838.969 478.533 835.214 479.309 831.618L550.199 503.223C553.38 488.487 575.061 490.802 575.061 505.878V927.397Z" fill="white"/>
+</g>
+<defs>
+<clipPath id="clip0_1177_97">
+<rect width="1200" height="1200" rx="600" fill="white"/>
+</clipPath>
+</defs>
+</svg>
@@ -0,0 +1,82 @@
+<svg width="1200" height="1200" viewBox="0 0 1200 1200" fill="none" xmlns="http://www.w3.org/2000/svg">
+<g clip-path="url(#clip0_1177_56)">
+<rect width="1200" height="1200" rx="600" fill="#FDFDFD"/>
+<path d="M806.896 -279.064C785.598 -313.026 733.108 -291.661 741.582 -252.479L1066.32 1248.94C1069.88 1265.41 1084.45 1277.16 1101.31 1277.16H1718.15C1746.29 1277.16 1763.42 1246.19 1748.47 1222.35L806.896 -279.064Z" fill="url(#paint0_radial_1177_56)" fill-opacity="0.04"/>
+<path d="M669.079 1606.13C669.079 1640.4 712.592 1655.08 733.354 1627.82L935.184 1362.81C941.526 1354.48 943.905 1343.8 941.696 1333.57L739.866 399.014C730.809 357.077 669.079 363.667 669.079 406.57L669.079 1606.13Z" fill="url(#paint1_radial_1177_56)" fill-opacity="0.04"/>
+<path d="M392.104 -279.064C413.403 -313.026 465.892 -291.661 457.418 -252.479L132.68 1248.94C129.117 1265.41 114.546 1277.16 97.692 1277.16H-519.146C-547.286 1277.16 -564.423 1246.19 -549.473 1222.35L392.104 -279.064Z" fill="url(#paint2_radial_1177_56)" fill-opacity="0.04"/>
+<path d="M529.921 1606.13C529.921 1640.4 486.408 1655.08 465.646 1627.82L263.816 1362.81C257.474 1354.48 255.095 1343.8 257.304 1333.57L459.134 399.014C468.191 357.077 529.921 363.667 529.921 406.57V1606.13Z" fill="url(#paint3_radial_1177_56)" fill-opacity="0.04"/>
+<path d="M672.345 264.951C664.864 253.017 646.428 260.525 649.404 274.293L763.463 801.88C764.715 807.668 769.833 811.799 775.752 811.799H992.407C1002.29 811.799 1008.31 800.915 1003.06 792.538L672.345 264.951Z" fill="url(#paint4_radial_1177_56)"/>
+<path d="M623.939 927.397C623.939 939.438 639.222 944.597 646.514 935.018L717.404 841.895C719.631 838.969 720.467 835.214 719.691 831.618L648.801 503.223C645.62 488.487 623.939 490.802 623.939 505.878L623.939 927.397Z" fill="url(#paint5_radial_1177_56)"/>
+<path d="M526.655 264.951C534.136 253.017 552.572 260.525 549.596 274.293L435.537 801.88C434.285 807.668 429.167 811.799 423.248 811.799H206.593C196.709 811.799 190.69 800.915 195.941 792.538L526.655 264.951Z" fill="url(#paint6_radial_1177_56)"/>
+<path d="M575.061 927.397C575.061 939.438 559.778 944.597 552.486 935.018L481.596 841.895C479.369 838.969 478.533 835.214 479.309 831.618L550.199 503.223C553.38 488.487 575.061 490.802 575.061 505.878V927.397Z" fill="url(#paint7_radial_1177_56)"/>
+</g>
+<defs>
+<radialGradient id="paint0_radial_1177_56" cx="0" cy="0" r="1" gradientTransform="matrix(755.281 3220.39 -3836.69 634.576 -633.706 -1346.76)" gradientUnits="userSpaceOnUse">
+<stop stop-color="#1BA1E3"/>
+<stop offset="0.0001" stop-color="#1BA1E3"/>
+<stop offset="0.300221" stop-color="#5489D6"/>
+<stop offset="0.545524" stop-color="#9B72CB"/>
+<stop offset="0.825372" stop-color="#D96570"/>
+<stop offset="1" stop-color="#F49C46"/>
+</radialGradient>
+<radialGradient id="paint1_radial_1177_56" cx="0" cy="0" r="1" gradientTransform="matrix(755.281 3220.39 -3836.69 634.576 -633.706 -1346.76)" gradientUnits="userSpaceOnUse">
+<stop stop-color="#1BA1E3"/>
+<stop offset="0.0001" stop-color="#1BA1E3"/>
+<stop offset="0.300221" stop-color="#5489D6"/>
+<stop offset="0.545524" stop-color="#9B72CB"/>
+<stop offset="0.825372" stop-color="#D96570"/>
+<stop offset="1" stop-color="#F49C46"/>
+</radialGradient>
+<radialGradient id="paint2_radial_1177_56" cx="0" cy="0" r="1" gradientTransform="matrix(755.281 3220.39 -3836.69 634.576 -633.706 -1346.76)" gradientUnits="userSpaceOnUse">
+<stop stop-color="#1BA1E3"/>
+<stop offset="0.0001" stop-color="#1BA1E3"/>
+<stop offset="0.300221" stop-color="#5489D6"/>
+<stop offset="0.545524" stop-color="#9B72CB"/>
+<stop offset="0.825372" stop-color="#D96570"/>
+<stop offset="1" stop-color="#F49C46"/>
+</radialGradient>
+<radialGradient id="paint3_radial_1177_56" cx="0" cy="0" r="1" gradientTransform="matrix(755.281 3220.39 -3836.69 634.576 -633.706 -1346.76)" gradientUnits="userSpaceOnUse">
+<stop stop-color="#1BA1E3"/>
+<stop offset="0.0001" stop-color="#1BA1E3"/>
+<stop offset="0.300221" stop-color="#5489D6"/>
+<stop offset="0.545524" stop-color="#9B72CB"/>
+<stop offset="0.825372" stop-color="#D96570"/>
+<stop offset="1" stop-color="#F49C46"/>
+</radialGradient>
+<radialGradient id="paint4_radial_1177_56" cx="0" cy="0" r="1" gradientTransform="matrix(274.644 1185.23 -1411.16 229.793 166.356 -110.23)" gradientUnits="userSpaceOnUse">
+<stop stop-color="#22B1F8"/>
+<stop offset="0.242027" stop-color="#1BA1E3"/>
+<stop offset="0.381789" stop-color="#5489D6"/>
+<stop offset="0.648677" stop-color="#9B72CB"/>
+<stop offset="0.866975" stop-color="#D96570"/>
+<stop offset="1" stop-color="#F49C46"/>
+</radialGradient>
+<radialGradient id="paint5_radial_1177_56" cx="0" cy="0" r="1" gradientTransform="matrix(274.644 1185.23 -1411.16 229.793 166.356 -110.23)" gradientUnits="userSpaceOnUse">
+<stop stop-color="#22B1F8"/>
+<stop offset="0.242027" stop-color="#1BA1E3"/>
+<stop offset="0.381789" stop-color="#5489D6"/>
+<stop offset="0.648677" stop-color="#9B72CB"/>
+<stop offset="0.866975" stop-color="#D96570"/>
+<stop offset="1" stop-color="#F49C46"/>
+</radialGradient>
+<radialGradient id="paint6_radial_1177_56" cx="0" cy="0" r="1" gradientTransform="matrix(274.644 1185.23 -1411.16 229.793 166.356 -110.23)" gradientUnits="userSpaceOnUse">
+<stop stop-color="#22B1F8"/>
+<stop offset="0.242027" stop-color="#1BA1E3"/>
+<stop offset="0.381789" stop-color="#5489D6"/>
+<stop offset="0.648677" stop-color="#9B72CB"/>
+<stop offset="0.866975" stop-color="#D96570"/>
+<stop offset="1" stop-color="#F49C46"/>
+</radialGradient>
+<radialGradient id="paint7_radial_1177_56" cx="0" cy="0" r="1" gradientTransform="matrix(274.644 1185.23 -1411.16 229.793 166.356 -110.23)" gradientUnits="userSpaceOnUse">
+<stop stop-color="#22B1F8"/>
+<stop offset="0.242027" stop-color="#1BA1E3"/>
+<stop offset="0.381789" stop-color="#5489D6"/>
+<stop offset="0.648677" stop-color="#9B72CB"/>
+<stop offset="0.866975" stop-color="#D96570"/>
+<stop offset="1" stop-color="#F49C46"/>
+</radialGradient>
+<clipPath id="clip0_1177_56">
+<rect width="1200" height="1200" rx="600" fill="white"/>
+</clipPath>
+</defs>
+</svg>
@@ -0,0 +1,20 @@
+<svg width="1200" height="1200" viewBox="0 0 1200 1200" fill="none" xmlns="http://www.w3.org/2000/svg">
+<g clip-path="url(#clip0_1177_50)">
+<rect width="1200" height="1200" rx="600" fill="#2B2242"/>
+<g opacity="0.07">
+<path d="M806.896 -279.064C785.598 -313.026 733.108 -291.661 741.582 -252.479L1066.32 1248.94C1069.88 1265.41 1084.45 1277.16 1101.31 1277.16H1718.15C1746.29 1277.16 1763.42 1246.19 1748.47 1222.35L806.896 -279.064Z" fill="#C3AEFF"/>
+<path d="M669.079 1606.13C669.079 1640.4 712.592 1655.08 733.354 1627.82L935.184 1362.81C941.526 1354.48 943.905 1343.8 941.696 1333.57L739.866 399.014C730.809 357.077 669.079 363.667 669.079 406.57L669.079 1606.13Z" fill="#C3AEFF"/>
+<path d="M392.104 -279.064C413.403 -313.026 465.892 -291.661 457.418 -252.479L132.68 1248.94C129.117 1265.41 114.546 1277.16 97.692 1277.16H-519.146C-547.286 1277.16 -564.423 1246.19 -549.473 1222.35L392.104 -279.064Z" fill="#C3AEFF"/>
+<path d="M529.921 1606.13C529.921 1640.4 486.408 1655.08 465.646 1627.82L263.816 1362.81C257.474 1354.48 255.095 1343.8 257.304 1333.57L459.134 399.014C468.191 357.077 529.921 363.667 529.921 406.57V1606.13Z" fill="#C3AEFF"/>
+</g>
+<path d="M672.345 264.951C664.864 253.017 646.428 260.525 649.404 274.293L763.463 801.88C764.715 807.668 769.833 811.799 775.752 811.799H992.407C1002.29 811.799 1008.31 800.915 1003.06 792.538L672.345 264.951Z" fill="#C3AEFF"/>
+<path d="M623.939 927.397C623.939 939.438 639.222 944.597 646.514 935.018L717.404 841.895C719.631 838.969 720.467 835.214 719.691 831.618L648.801 503.223C645.62 488.487 623.939 490.802 623.939 505.878L623.939 927.397Z" fill="#DCCFFF"/>
+<path d="M526.655 264.951C534.136 253.017 552.572 260.525 549.596 274.293L435.537 801.88C434.285 807.668 429.167 811.799 423.248 811.799H206.593C196.709 811.799 190.69 800.915 195.941 792.538L526.655 264.951Z" fill="#F5F5F5"/>
+<path d="M575.061 927.397C575.061 939.438 559.778 944.597 552.486 935.018L481.596 841.895C479.369 838.969 478.533 835.214 479.309 831.618L550.199 503.223C553.38 488.487 575.061 490.802 575.061 505.878V927.397Z" fill="#F5F5F5"/>
+</g>
+<defs>
+<clipPath id="clip0_1177_50">
+<rect width="1200" height="1200" rx="600" fill="white"/>
+</clipPath>
+</defs>
+</svg>
@@ -0,0 +1,20 @@
+<svg width="1200" height="1200" viewBox="0 0 1200 1200" fill="none" xmlns="http://www.w3.org/2000/svg">
+<g clip-path="url(#clip0_1177_53)">
+<rect width="1200" height="1200" rx="600" fill="#5865F2"/>
+<g opacity="0.13">
+<path d="M806.896 -279.064C785.598 -313.026 733.108 -291.661 741.582 -252.479L1066.32 1248.94C1069.88 1265.41 1084.45 1277.16 1101.31 1277.16H1718.15C1746.29 1277.16 1763.42 1246.19 1748.47 1222.35L806.896 -279.064Z" fill="#C3AEFF"/>
+<path d="M669.079 1606.13C669.079 1640.4 712.592 1655.08 733.354 1627.82L935.184 1362.81C941.526 1354.48 943.905 1343.8 941.696 1333.57L739.866 399.014C730.809 357.077 669.079 363.667 669.079 406.57L669.079 1606.13Z" fill="#C3AEFF"/>
+<path d="M392.104 -279.064C413.403 -313.026 465.892 -291.661 457.418 -252.479L132.68 1248.94C129.117 1265.41 114.546 1277.16 97.692 1277.16H-519.146C-547.286 1277.16 -564.423 1246.19 -549.473 1222.35L392.104 -279.064Z" fill="#C3AEFF"/>
+<path d="M529.921 1606.13C529.921 1640.4 486.408 1655.08 465.646 1627.82L263.816 1362.81C257.474 1354.48 255.095 1343.8 257.304 1333.57L459.134 399.014C468.191 357.077 529.921 363.667 529.921 406.57V1606.13Z" fill="#C3AEFF"/>
+</g>
+<path d="M672.345 264.951C664.864 253.017 646.428 260.525 649.404 274.293L763.463 801.88C764.715 807.668 769.833 811.799 775.752 811.799H992.407C1002.29 811.799 1008.31 800.915 1003.06 792.538L672.345 264.951Z" fill="white"/>
+<path d="M623.939 927.397C623.939 939.438 639.222 944.597 646.514 935.018L717.404 841.895C719.631 838.969 720.467 835.214 719.691 831.618L648.801 503.223C645.62 488.487 623.939 490.802 623.939 505.878L623.939 927.397Z" fill="white"/>
+<path d="M526.655 264.951C534.136 253.017 552.572 260.525 549.596 274.293L435.537 801.88C434.285 807.668 429.167 811.799 423.248 811.799H206.593C196.709 811.799 190.69 800.915 195.941 792.538L526.655 264.951Z" fill="white"/>
+<path d="M575.061 927.397C575.061 939.438 559.778 944.597 552.486 935.018L481.596 841.895C479.369 838.969 478.533 835.214 479.309 831.618L550.199 503.223C553.38 488.487 575.061 490.802 575.061 505.878V927.397Z" fill="white"/>
+</g>
+<defs>
+<clipPath id="clip0_1177_53">
+<rect width="1200" height="1200" rx="600" fill="white"/>
+</clipPath>
+</defs>
+</svg>
@@ -0,0 +1,36 @@
+<svg width="1200" height="1200" viewBox="0 0 1200 1200" fill="none" xmlns="http://www.w3.org/2000/svg">
+<g clip-path="url(#clip0_1177_68)">
+<rect width="1200" height="1200" rx="600" fill="#E83030"/>
+<g opacity="0.09">
+<path d="M806.896 -279.064C785.598 -313.026 733.108 -291.661 741.582 -252.479L1066.32 1248.94C1069.88 1265.41 1084.45 1277.16 1101.31 1277.16H1718.15C1746.29 1277.16 1763.42 1246.19 1748.47 1222.35L806.896 -279.064Z" fill="#F6F6F6"/>
+<path d="M669.079 1606.13C669.079 1640.4 712.592 1655.08 733.354 1627.82L935.184 1362.81C941.526 1354.48 943.905 1343.8 941.696 1333.57L739.866 399.014C730.809 357.077 669.079 363.667 669.079 406.57L669.079 1606.13Z" fill="#F6F6F6"/>
+<path d="M392.104 -279.064C413.403 -313.026 465.892 -291.661 457.418 -252.479L132.68 1248.94C129.117 1265.41 114.546 1277.16 97.692 1277.16H-519.146C-547.286 1277.16 -564.423 1246.19 -549.473 1222.35L392.104 -279.064Z" fill="#F6F6F6"/>
+<path d="M529.921 1606.13C529.921 1640.4 486.408 1655.08 465.646 1627.82L263.816 1362.81C257.474 1354.48 255.095 1343.8 257.304 1333.57L459.134 399.014C468.191 357.077 529.921 363.667 529.921 406.57V1606.13Z" fill="#F6F6F6"/>
+</g>
+<path d="M672.345 264.951C664.864 253.017 646.428 260.525 649.404 274.293L763.463 801.88C764.715 807.668 769.833 811.799 775.752 811.799H992.407C1002.29 811.799 1008.31 800.915 1003.06 792.538L672.345 264.951Z" fill="url(#paint0_linear_1177_68)" fill-opacity="0.9"/>
+<path d="M623.939 927.397C623.939 939.438 639.222 944.597 646.514 935.018L717.404 841.895C719.631 838.969 720.467 835.214 719.691 831.618L648.801 503.223C645.62 488.487 623.939 490.802 623.939 505.878L623.939 927.397Z" fill="url(#paint1_linear_1177_68)" fill-opacity="0.9"/>
+<path d="M526.655 264.951C534.136 253.017 552.572 260.525 549.596 274.293L435.537 801.88C434.285 807.668 429.167 811.799 423.248 811.799H206.593C196.709 811.799 190.69 800.915 195.941 792.538L526.655 264.951Z" fill="url(#paint2_linear_1177_68)" fill-opacity="0.9"/>
+<path d="M575.061 927.397C575.061 939.438 559.778 944.597 552.486 935.018L481.596 841.895C479.369 838.969 478.533 835.214 479.309 831.618L550.199 503.223C553.38 488.487 575.061 490.802 575.061 505.878V927.397Z" fill="url(#paint3_linear_1177_68)" fill-opacity="0.9"/>
+</g>
+<defs>
+<linearGradient id="paint0_linear_1177_68" x1="599.5" y1="259" x2="599.5" y2="940" gradientUnits="userSpaceOnUse">
+<stop stop-color="white"/>
+<stop offset="1" stop-color="white" stop-opacity="0.6"/>
+</linearGradient>
+<linearGradient id="paint1_linear_1177_68" x1="599.5" y1="259" x2="599.5" y2="940" gradientUnits="userSpaceOnUse">
+<stop stop-color="white"/>
+<stop offset="1" stop-color="white" stop-opacity="0.6"/>
+</linearGradient>
+<linearGradient id="paint2_linear_1177_68" x1="599.5" y1="259" x2="599.5" y2="940" gradientUnits="userSpaceOnUse">
+<stop stop-color="white"/>
+<stop offset="1" stop-color="white" stop-opacity="0.6"/>
+</linearGradient>
+<linearGradient id="paint3_linear_1177_68" x1="599.5" y1="259" x2="599.5" y2="940" gradientUnits="userSpaceOnUse">
+<stop stop-color="white"/>
+<stop offset="1" stop-color="white" stop-opacity="0.6"/>
+</linearGradient>
+<clipPath id="clip0_1177_68">
+<rect width="1200" height="1200" rx="600" fill="white"/>
+</clipPath>
+</defs>
+</svg>
--- a/Show More
+++ b/Show More