> Release sections in this journal are historical snapshots. The present project direction and current checkpoint are defined by the latest dated entry and the current roadmap sections below. ## 2026-10-03 — Alpha.50.9.12 environment-separation candidate - Make the Telegram bot Mini App URL configurable through `MINI_APP_URL`. - Preserve `https://im-test.bktis.ru/apps/miniapp/` as the staging fallback. - Prepare the same release-managed codebase to serve future production at `https://digidala.ru/apps/miniapp/`. - Keep the current test bot `@PixDala_bot` and test infrastructure unchanged. - Do not introduce production DNS, HTTPS, systemd, database or bot deployment in this release. - The future production bot is `@DigiDala_bot`. - Candidate Alpha.50.9.12 is local only until it passes the usual commit → tag → staging deploy → Telegram QA workflow. ## 2026-10-03 — Alpha.50.9.11 verified legal-document checkpoint - Add English source and generated versions of the four public legal documents. - Route Mini App legal links to the active RU/EN document set. - Route Telegram bot legal commands and `/paysupport` to the user's saved RU/EN document set. - Keep the existing Russian public URLs stable. - Open legal documents inside Telegram WebView using private-chat `web_app` buttons and group-chat Main Mini App `startapp` deep links. - Keep Mini App footer legal links in the current WebView instead of opening a new browser tab. - Preserve all existing Mandala, payment, moderation, navigation and locale-persistence mechanics. - Released as `v0.4.0-alpha.50.9.11` from commit `21fb337` and deployed to the test VPS. - Automated verification passed 134/134 on both local and VPS checks. - Manual Telegram checking reported the legal-document flows working. ## 2026-10-03 — Alpha.50.9.9 verified; technical QA checkpoint complete - Carries forward the Alpha.50.9.8 report-control readability and moderator-notification improvements. - Adds the missing `mandala_cols` repository field required by the moderator-notification coordinate calculation. - Applies the `report-action` styling hook to both Mini App report controls so the dedicated readable secondary style is used by the rendered buttons. - The earlier `v0.4.0-alpha.50.9.8` tag was superseded before deployment; no Alpha.50.9.8 release was deployed. - Released and deployed exact tag `v0.4.0-alpha.50.9.9` from commit `7b9c70a`. - Automated verification passes 131/131: Structure OK, JavaScript syntax OK, Unit 50/50, Integration 58/58, API 23/23. - Manual Telegram/Mini App QA passed for report-button readability, moderator complaint context (reason, comment, cell number and row/column coordinates), and Mini App reload behavior after release. - The test-VPS Nginx HTML cache policy was validated in the live Mini App: the new release was picked up without manual cache clearing; versioned JavaScript and CSS remained normally cacheable. - The technical moderation/localization/cache-refresh checkpoint is complete. - Next product phase: Terms/User Agreement and Rules/Policies, followed by staged production-infrastructure setup and controlled Telegram distribution. ## 2026-10-03 — Alpha.50.9.8 candidate superseded before deployment - Tag `v0.4.0-alpha.50.9.8` was created from commit `51c1fef` as a candidate for report-control styling and richer moderator complaint context. - Before deployment, a review found that the candidate tag did not yet contain the follow-up `mandala_cols` repository field or the `report-action` hooks in `apps/miniapp/index.html`. - Those two missing pieces were added in commits `45cb428` and `8aa0f40`; the resulting state is tracked as the Alpha.50.9.9 candidate. - Alpha.50.9.8 was not deployed to the test VPS and therefore has no manual deployment/QA claim. ## 2026-10-03 — Alpha.50.9.7 verified; Mini App cache policy corrected on test VPS - Released and deployed exact tag `v0.4.0-alpha.50.9.7` from commit `42b3a62`. - Automated verification passed 129/129: Structure OK, JavaScript syntax OK, Unit 48/48, Integration 58/58, API 23/23. - Manual Telegram/Mini App QA passed for moderation quarantine, active-client moderation synchronization, Bot↔Mini App locale synchronization and completion/destruction of a Mandala while its visual is hidden. A new cycle restored the visual as expected. - Static-asset cache-busting was added to `apps/miniapp/index.html` for versioned `app.js` and `styles.css` URLs. - Test VPS Nginx was then adjusted outside the code release to return `Cache-Control: no-store, no-cache, must-revalidate, max-age=0`, `Pragma: no-cache` and `Expires: 0` for `/apps/miniapp/` and `/apps/miniapp/index.html`, while versioned JavaScript/CSS remain normally cacheable. ## 2026-10-03 — Alpha.50.9.6 verified - Released and deployed exact tag `v0.4.0-alpha.50.9.6` from commit `ea7d839`. - Whole-Mandala quarantine replaces the original artwork with a neutral in-place moderation state while keeping the cell structure visible. - Public moderation changes advance the affected Mandala `revision`, so the existing client synchronization path propagates hide/restore/quarantine changes to already-open Mini Apps without a manual refresh. - Telegram bot and Mini App manual locale changes use the same persistent per-user locale preference; manual QA confirmed RU↔EN synchronization in both directions. - Automated verification passed 129/129: Structure OK, JavaScript syntax OK, Unit 48/48, Integration 58/58, API 23/23. - Manual Telegram/Mini App QA passed, including completion/destruction with a hidden visual and restoration of the visual on the next cycle. ## 2026-10-02 — Alpha.50.9.5 verified; post-moderation QA checkpoint - Released and deployed exact tag `v0.4.0-alpha.50.9.5` from commit `4dbe56b`. - Alpha.50.9.4 introduced the first post-moderation workflow: cell-content complaints, mandala-visual complaints, Telegram moderator actions, cycle-bound moderation state and preservation of participation/payment history. - Alpha.50.9.5 fixed the Mini App cell-report flow so the report form replaces the occupied-cell detail dialog instead of opening underneath it; the report target is preserved through submission. - Automated verification for the current state passed 126/126: Structure OK, JavaScript syntax OK, Unit 47/47, Integration 57/57, API 22/22. - Manual Telegram/Mini App QA passed for submitting a cell-content complaint and processing a mandala-visual complaint. - Open moderation presentation issue: when the whole Mandala visual is quarantined, the underlying artwork remains partially visible beneath the cell layer as a darkened/desaturated image; the explanation is not presented directly inside the visual area. The next fix must replace the artwork with a neutral quarantine state and show the moderation notice in the visual area itself. - Open moderation synchronization issue: after a moderator changes the moderation state, an already-open Mini App does not reflect the result until the page is refreshed or the app is restarted. The desired behavior is to propagate moderation state to active clients without manual reload, preferably by extending the existing server-state synchronization/polling path before introducing a new realtime transport. - The next moderation QA checkpoint is therefore limited to these two follow-ups: quarantine-visual presentation and active-client moderation-state propagation. - Alpha.50.9.5 was the moderation QA checkpoint; its two open follow-ups were resolved and verified by Alpha.50.9.6. ## 2026-10-02 — Alpha.50.9.2 verified; Telegram localization QA passed - Released and deployed exact tag `v0.4.0-alpha.50.9.2` from commit `75c430c`. - Automated verification: Structure OK, JavaScript syntax OK, Unit 43/43, Integration 50/50, API 17/17 (110/110 total). - Applied `018_bot_localization_newline_fix.sql` to repair literal `\n` system-default welcome content. - Manual Telegram QA passed: English welcome renders real line breaks; switching RU↔EN immediately replaces the current welcome and keyboard without a separate notice or a second `/start`. ## 2026-10-02 — Alpha.50.9.1 verified; Telegram bot RU/EN localization complete - Released and deployed exact tag `v0.4.0-alpha.50.9.1` from commit `3200550`. - Automated verification: Structure OK, JavaScript syntax OK, Unit 42/42, Integration 49/49, API 17/17 (108/108 total). - Manual Telegram QA passed for RU/EN language selection, persisted preference and localized bot content. - The approved Russian `О нас` text was restored through the admin content editor after legacy test-database content was observed; this was runtime data correction only. ## 2026-09-24 — Alpha.50.6.8 deployed; initial manual QA passed - Deploy the archive/navigation/cache-busting release from the exact tag `v0.4.0-alpha.50.6.8`. - Preserve the user-visible archive scope for Special and Competitive Mandalas only. - Keep empty Special/Competitive spaces reachable through the carousel and make the full carousel circular. - Add a permanent Archive index and generation-specific campaign/archive artwork URL versions. - Automated verification passed 84/84. - Exact tag `v0.4.0-alpha.50.6.8` was committed as `6af8591`, pushed to GitHub and deployed successfully. - Initial manual Telegram QA passed for Archive entry/index behavior, empty campaign-space navigation, circular left/right traversal and the previously affected Competitive artwork-cache case. - Two Competitive campaigns were created for queued-lifecycle verification. - The complete Competitive lifecycle through winner determination, destruction, archive and automatic activation of the next queued campaign remains open. ## 2026-09-23 — Alpha.50.6.7 verified - Replace the current browser-URL copy behavior with Telegram Main Mini App share links. - Generate stable start parameters for ordinary, Special, Competitive and QA campaign Mandalas. - Improve share-button contrast and copied-state feedback. - Add focused unit coverage for link generation. - Automated verification passed: 82/82. - Exact tag `v0.4.0-alpha.50.6.7` was committed as `42445ea`, pushed and deployed successfully. - Manual Telegram QA passed for share links under all tested Mandala types: ordinary, Special, Competitive, Support and Creative. The links open the requested Mandala in the Mini App and no longer expose Telegram WebApp runtime data. - The full Competitive lifecycle remains a separate open manual verification item. ## 2026-09-23 — Alpha.50.6.6 verified - Fix stale-state navigation between ordinary Mandalas and active Special/Competitive spaces. - Restart synchronization after successful special-space navigation and reject stale in-flight responses from the previous route. - Show a load-error state instead of misreporting API/bootstrap failures as an empty space. - Automated verification passed 79/79. - Exact tag `v0.4.0-alpha.50.6.6` was committed as `d07f2ce`, pushed and deployed successfully. - Manual Telegram QA passed for left/right navigation into active Special and Competitive spaces without a page refresh; the previous false empty-state behavior was not reproduced. - The full Competitive lifecycle remains a separate open manual verification item. ## 2026-09-23 — Alpha.50.6.5 verified - Fix the Competitive `/new_competitive` confirmation failure when a new campaign is queued behind an already active Competitive campaign. - Normalize the internal Competitive creation response so active and queued campaigns both expose the concrete Mandala under `campaign.mandala`. - Preserve the Alpha.50.6.4 fixed size choices 36/100/400 unchanged. - Automated verification passed 77/77. - Exact tag `v0.4.0-alpha.50.6.5` was committed as `25d4186`, pushed and deployed successfully. - Manual Telegram QA confirmed queued Competitive campaign creation while another Competitive campaign is active. ## 2026-09-23 — Alpha.50.6.4 deployed; follow-up fixed in Alpha.50.6.5 - Add exactly three administrator-selectable Competitive Mandala sizes in `/new_competitive`: 36 (6×6), 100 (10×10) and 400 (20×20). - Keep 400 as the backend default for compatibility with existing callers. - Verify that Competitive winner logic remains dimension-driven for the selected field size. - Update the post-destruction campaign message to the explicitly requested wording. - Automated verification passed 77/77. - Exact tag `v0.4.0-alpha.50.6.4` was committed as `fe368c5`, pushed and deployed successfully; manual QA later exposed the queued-creation response-shape defect fixed in Alpha.50.6.5. ## 2026-09-19 — Alpha.50.6.1 deployed; Competitive QA almost complete - Fix the Competitive Mandala API/bootstrap status so a successfully loaded competitive state displays `Синхронизировано`. - Make the competitive cell price administrator-defined during bot creation. - Add `/competitive_edit ` for price/description edits; lock price changes after first occupation. - Include the active Competitive Mandala in the existing left/right navigation list without adding it to the regular cyclic catalog. - Add a competitive-only center divider between the two 10-column halves of the 20×20 field. - Add regression coverage proving that existing Mandala types retain their catalog, navigation, pricing and rendering behavior. - Automated verification passed: 71/71. - Exact tag `v0.4.0-alpha.50.6.1` was committed, pushed and deployed successfully. - Manual Telegram QA passed on Mobile and Desktop for Competitive synchronization, navigation, configurable pricing, editing, occupation, center divider and regression scenarios. - The only remaining manual QA item is the full Competitive lifecycle: one side reaches 200 cells → `winner_side` → `destroying` → `archived` → next queued Competitive becomes active. ## 2026-09-18 — Alpha50.5.9 verified - Refine the Daughter campaign progress hint so the trembling state reports the actual number of remaining cells with correct Russian forms. - Remove the extra CTA sentence from the Daughter campaign description and apply the cleanup to existing `daughter` / `daughter-qa` records through migration `014_daughter_copy_cleanup.sql`. - Automated verification passed 66/66; `v0.4.0-alpha.50.5.9` was committed as `ab31892`, tagged, pushed and deployed successfully. - Manual Telegram QA passed for the Daughter campaign, including progress copy, cleaned description, destruction/archive flow and participant trace presentation. - Temporary QA campaign `daughter-qa` was removed after verification; the QA campaign list is now empty. ## 2026-09-17 — Alpha50.5.4 verified - Restore the destruction preview artwork resolution for ordinary and campaign Mandalas. - Preserve the Alpha50.5.3 campaign-state and navigation fixes unchanged. - Automated verification passed 66/66; release tagged and deployed successfully. - Manual Telegram QA passed for Sandbox and Small Creative destruction, including sound, particle animation, post-destruction state and navigation. Historical Alpha50.5.1 follow-up: - Fix mobile first-viewport composition so the Mandala appears before the status block on narrow Telegram screens. - Restore active campaign Mandala in ordinary left/right navigation and swipe. - Keep campaigns out of the regular catalog while exposing a navigation-only active campaign item. # DigiDala — Working Roadmap ## 1. Historical product roadmap This is the surviving original roadmap from the `v0.1.1` baseline. It is kept here as historical product intent and is not rewritten retroactively. 1. Baseline and safe workflow 2. Backend core 3. Telegram Mini App integration 4. Telegram Test payment flow 5. Pix Economy + Ledger 6. Rewards + Основатель 7. Patterns 8. Multilingual 9. Charity / Event / Community / Sponsor / Challenge 10. Profiles + Archive 11. Admin 12. Web for desktop 13. Integrations / creator platform Cross-cutting requirements from the original roadmap: - Telegram-native performance; - testing; - documentation; - rollback; - security; - design iteration. The original `0.1.0` baseline was explicitly a visual-functional comparison point. Backend, Telegram integration, production payment, Pix Economy, Patterns, Charity and the multilingual production layer were not considered final there. --- ## 2. What actually happened The project evolved from the visual baseline into a server-backed application. The main architectural progression was: ```text 0.1.0 visual-functional baseline ↓ 0.2.0-alpha domain core + lifecycle ↓ 0.3.x persistence + API + Telegram initData validation + server authority ↓ 0.4.x Mini App → API + synchronization + reliability work ↓ alpha.28 verified client baseline promoted into main ↓ alpha.32 verified Mandala Sandbox test checkpoint ↓ alpha.33 server-authoritative lifecycle verified ``` The domain/lifecycle architecture is now explicit: ```text draft → active → trembling → complete → destroying → archived ``` The backend/domain layer is authoritative; the UI is not the source of truth. The current tagged engineering checkpoint is `v0.4.0-alpha.50.9.11`. Alpha.50.9.5 established the first post-moderation QA checkpoint; Alpha.50.9.6 resolved the quarantine-presentation and active-client synchronization follow-ups; Alpha.50.9.7 added static-asset cache-busting and the test-VPS HTML cache policy; Alpha.50.9.9 completed the final moderation-UX/context QA and verified release refresh without manual cache clearing. The technical moderation/localization/cache-refresh work is now complete for the current launch-readiness phase. The next product phase is legal/policy readiness: Terms/User Agreement and Rules/Policies, followed by DigiDala domain purchase and staged Telegram-group distribution. The Mandala Sandbox remains the default free introductory Mini App Mandala; the Support Mandala is the current paid-cell / Pix economy test object; the Daughter campaign is the verified first `campaigns` implementation. ### Historical status against the original roadmap | Original stage | Current status | Notes | |---|---|---| | 1. Baseline and safe workflow | Done / evolved | Baseline, deployment, rollback and testing workflow exist. | | 2. Backend core | Done | SQLite persistence, repositories and API exist. | | 3. Telegram Mini App integration | Done / core | Mini App, test bot, initData validation and server-backed occupation exist. | | 4. Telegram Test payment flow | Completed / evolved | Telegram Stars project-support payment foundation was verified in alpha.44; production-scale reconciliation remains. | | 5. Pix Economy + Ledger | Implemented / hardening | Alpha.49 introduced Pix ledger and paid Support cells; Alpha.49.2 makes cell debits cycle-scoped through first-class occupation events. | | 6. Rewards + Основатель | Future | No current implementation commitment. | | 7. Patterns | Future | Not implemented. | | 8. Multilingual | Implemented / verified | RU/EN Mini App localization was delivered through Alpha.50.9; Telegram bot RU/EN localization and manual language-switch QA were completed in Alpha.50.9.1–50.9.2. | | 9. Charity / Event / Community / Sponsor / Challenge | Future directions | Product modes remain future scope. | | 10. Profiles + Archive | Partial / in progress | Archive/lifecycle groundwork exists; full profiles/history remain future work. | | 11. Admin | Implemented / hardening | Alpha.50.6 introduced private bot administration with `content_admin` and `superadmin` roles; further operational hardening may remain. | | 12. Web for desktop | Future | Current focus remains Telegram Mini App. | | 13. Integrations / creator platform | Future | Not implemented. | This table is a current interpretation of the historical roadmap based on the actual project state. It should be updated when a roadmap stage materially changes. --- ## 3. Current engineering roadmap — P0 / Core ### P0.1 Reliable core before product expansion **Core reliability foundation is established. Alpha.45–48.3 extended the system with multi-Mandala routing, Creative Mandala support and Telegram navigation. Alpha.49–50.4 established the internal Pix economy and paid-cell hardening. Alpha.50.5–50.5.4 established and refined the first Особая мандала / `campaigns` foundation, including its archive lifecycle and destruction-preview repair. The Sandbox remains complete for its intended MVP role.** #### Development and deployment workflow The project now uses a local-first, GitHub-backed workflow: ```text VSCode on Windows → local Git → GitHub → tag → VPS deploy-test.sh → release/current ``` Source files are not edited manually on the VPS. Local changes must pass the project checks before commit; release deployment is performed from an explicit Git tag and uses the existing release/rollback mechanism. This workflow is part of the project engineering baseline because reproducibility and rollback are cross-cutting requirements of the roadmap. Historical checkpoint: `v0.4.0-alpha.32` passed its full local check and was deployed successfully from its Git tag. The current verified Telegram/Mini App checkpoint is `v0.4.0-alpha.48.3`. First make the existing core reliable, reproducible and simple before expanding payment or product features. Immediate controlled audit of the client reliability mechanisms inherited from experimental releases: 1. GET timeout (`45s`) 2. GET retry (`2 attempts`) 3. fresh `AbortController` per retry 4. occupation POST timeout (`15s`) 5. `bootstrapPromise` / `ensureBootstrap` 6. waiting for bootstrap before confirmation 7. server-state reconciliation 8. inline client-side domain model For every mechanism: - identify when it was introduced; - identify the concrete failure it addressed; - check whether that failure is still relevant; - simplify only when there is sufficient evidence; - make one controlled change at a time; - run automated/manual verification appropriate to the change. The `45s` GET timeout was intentionally introduced in alpha.18 for slow Telegram mobile connections. Its continued value is still an empirical question; it must not be removed merely because the number looks arbitrary. ### P0.1a Release-managed Telegram test bot **Alpha.36.1 fix prepared.** Goals: - move the test bot source into Git; - use a stable Mini App URL without a release version; - run the bot from `/opt/pixdala/current`; - deploy and rollback the bot together with web and API; - configure the Telegram Menu Button to the stable Mini App entry point. This removes the recurring manual `scp` + systemd restart step used during alpha.33–35 and makes old Telegram messages resilient to later releases because they point to the stable entry path. ### P0.1g Telegram group navigation and Main Mini App configuration — alpha.48.3 Alpha.48–48.3 added group-friendly Telegram navigation for Sandbox, Support and Creative, plus the existing project-support flow. The Mini App routing already supported the required start-parameter sources. The observed Android behavior (all links opening Sandbox) and Desktop `BOT_INVALID` were caused by the absence of a configured **Main Mini App** for `@PixDala_bot`, not by the Mini App routing implementation. Configuring the Main Mini App in BotFather to the stable URL `https://im-test.bktis.ru/apps/miniapp/` resolved the issue without further code changes. Verified manually on Android and Desktop: - group `🪷 Открыть DigiDala` → Main Mini App → Sandbox; - group `🤝 Мандала поддержки` → Support; - group `🎨 Мандала творчества` → Creative; - `⭐ Поддержать проект` → private bot support flow, unchanged; - private `web_app` launch and Menu Button remain functional. This Telegram configuration is now part of the operational deployment checklist for any future bot/Mini App migration. ### P0.1b Multi-user Mandala synchronization foundation **Next after alpha.36a.** The client must observe changes made by other users without restarting the Mini App. The first implementation should use a server-side Mandala state version and periodic polling. A background sync may update Mandala/cell state but must never replace text that the current user is actively editing. Successful occupation must return the current server-authoritative state. The architecture should keep the visual Mandala layer and message layer separable so that future realtime transport (SSE/WebSocket) can be introduced without redesigning the product state model. ### P0.1a Multi-client Mandala synchronization **Alpha.37 foundation prepared.** - Add a monotonic `mandalas.revision` to the server model. - Poll the authoritative Mandala snapshot about every 2 seconds. - Refresh on tab/app visibility return. - Never overwrite a message draft during background synchronization. - Handle the selected-cell race explicitly when another participant occupies it. - Rebuild client domain state from the server snapshot so reset cannot leave stale cells. Next after this foundation: - separate Mandala visual state from participant/message state; - then evaluate whether SSE/WebSocket is justified by real usage. ### P0.1c Shared Mandala UX hardening — alpha.38 **Completed and released.** Alpha.38 established unique participant counting, occupation audio behavior, completion-overlay layering work, and the initial client-side response to server-authoritative destruction. Manual testing then identified the remaining Desktop overlay and remote-destruction issues that were resolved in alpha.39. ### P0.1d Shared Mandala completion/destruction follow-up — alpha.39 **Completed and verified.** Alpha.39 resolved the alpha.38 manual findings: 1. corrected Desktop completion-overlay stacking; 2. added viewer-specific completion copy; 3. corrected remote destruction animation startup when polling observes server `destroying`; 4. preserved server-authoritative reset and existing revision polling; 5. preserved cross-viewer occupation audio. Automated verification: 35/35. Manual Telegram verification on Mobile and Desktop passed with multiple users. After alpha.39, return to the planned separation of Mandala visual state and participant/message state, then evaluate SSE/WebSocket only if real usage justifies it. ### P0.1e Release continuity and AI handoff — alpha.40 **Completed as a superseded release candidate.** Alpha.40 added `AI_HANDOFF.md` and synchronized the project journals, but its final-participant text change targeted the `stageOverlay` rather than the visible `celebrate` completion card. Manual Telegram verification exposed this mismatch. Alpha.40 was deployed but was not accepted as the verified checkpoint. Its tag remains immutable and is superseded by alpha.41. ### P0.1f Final-participant completion copy correction — alpha.41 **Completed and verified.** Alpha.41 corrected the actual `celebrate` completion card used by the Mini App. Exact verified final-participant UI: ```text Мандала завершена! Пора отпустить созданное... ``` The existing action button remains: ```text Развеять мандалу ``` Automated verification: 35/35. Deployment: `v0.4.0-alpha.41`. Manual Telegram verification passed on Mobile and Desktop. The server-authoritative lifecycle, revision polling, remote destruction visualization, destroyer-only reset and accepted cross-viewer occupation audio remain unchanged. The current verified checkpoint is alpha.41. The Sandbox is now treated as the default introductory Mandala for the Mini App: its purpose is to let a user understand the interface and the core Mandala mechanics without payment. The next product stage is deliberately not a realtime-transport expansion. Payment and economic foundations now take priority. ### P0.2 Complete the lifecycle **Alpha.33 server-authoritative lifecycle verified; continue toward archive hardening.** The lifecycle must remain owned by the domain/application layer rather than UI state. Alpha.33 verified: - server authorization of the final acquirer / destroyer; - destruction state handling; - automatic sandbox reset after the ritual; - recovery of stale `destroying` state; - real Telegram verification on Mobile and Desktop. The next lifecycle work should focus on the durable archive/history side rather than re-opening the verified destruction/reset path without evidence. ### P0.2a Occupied-cell presentation refinement — alpha.34 A small UI refinement is currently prepared locally: - text-sized user/message icons; - icon and corresponding text kept on the same row; - metadata block centered inside the cell; - stable vertical position when name/message line counts differ; - cell-width-constrained metadata on Desktop and Mobile. This is presentation-only and must not alter the verified alpha.33 lifecycle. It should be released only after Desktop and Mobile visual verification. ### P0.3 Archive / historical object Continue the archive direction: - persistent completed-object identity; - immutable archived state; - participation history sufficient for the core product; - clear transition from one completed object to the next cycle. Do not prematurely implement the full future social/profile system. ### P0.3a Особые мандалы / `campaigns` — alpha.50.5–50.5.9 verified The first campaign implementation extends the archive direction into a distinct short-lived product object: - user-facing space: **Особые мандалы**; - technical model: `campaigns`; - permanent Mini App / bot entry point independent of any specific campaign Mandala; - campaign Mandala lifecycle ends at `archived` and never starts a new cycle; - immutable archive stores the goal, dates, final artwork, participation totals, per-participant contribution and non-empty cell messages; - participant-level archive traces are exposed with deterministic participant colors and whole-trace hover highlighting; - archived message-bearing cells use participant-colored transparent message icons; - Telegram archive deep links use `startapp=archive-`; - after destruction the client shows a thank-you state and a link to the archive; - campaign Mandalas remain outside the regular cyclic Mandala catalog. The Daughter campaign is the first verified implementation target. Its end-to-end QA flow is established, including a temporary `daughter-qa` copy created for manual testing and removed afterwards. Do not expand this into a general creator platform yet. ### Ready-made file/archive workflow When a change can be safely prepared as a complete file, prefer a ready-to-replace file or ZIP archive over manual line edits. This improves speed while preserving the same verification discipline. ```text analyze → prepare file/archive → local replacement → npm.cmd run check → inspect diff → commit → GitHub → tag → VPS deploy → relevant manual test ``` For files outside the main repository, use an explicit transfer such as `scp`, verify the file on the VPS, and restart only the affected service. Prepared files do not bypass testing, review, Git history, or reproducible deployment. ### P0.4 Operational safety - database backups; - backup verification; - restore procedure; - reproducible GitHub-to-VPS test deployment; - rollback verification; - operational documentation; - keep VPS source copies as deployment inputs rather than manual development workspaces. ### P0.5 DigiDala economic foundation — Stars → pix **Next major development stage after the completed Mandala Sandbox.** The first real economic path should separate Telegram's external payment mechanism from DigiDala's internal currency. #### P0.5a Telegram Stars payment foundation — completed in alpha.44 Implemented and verified: - permanent Telegram Stars project-support flow; - payment initiation and server-side verification; - successful-payment finalization with durable SQLite records; - idempotency and duplicate-payment protection; - Telegram-user association and Telegram charge ID storage; - end-to-end Telegram testing with a real 1-Star payment. The Sandbox remains free. Stars are the external funding/payment rail and do not become the participant balance model inside the application. Remaining hardening before production-scale use: reconciliation/recovery of pending intents when an invoice is abandoned or closed without a successful payment event. #### P0.5b pix / pixcoin ledger Introduce the internal DigiDala currency layer: ```text Telegram Stars ↓ acquire pix ↓ pix balance / ledger ↓ spend pix in a Mandala ``` The ledger should be server-authoritative and auditable. Do not model the economy as a single mutable balance without transaction history. The currency model should allow more than one pix type, even if the MVP starts with only one type. Initial MVP goals: - acquire pix with Stars; - maintain an auditable ledger; - show current spendable balance; - debit pix atomically for a successful Mandala action; - prevent duplicate charging; - keep payment and currency state reconcilable. #### P0.5d Mandala identity and sharing foundation The full product stage remains future work: as multiple real Mandalas are introduced, each Mandala should have a stable public identity and shareable entry point. Alpha.45 implemented part of this foundation early as an infrastructure/capacity experiment. It established: - stable `sandbox` and `support` identifiers; - shareable slug-based entry; - explicit Mandala switching by arrows and swipe; - a separate 100-cell support Mandala for capacity testing; - stable public name **Мандала поддержки**. The roadmap now treats the existing **Мандала поддержки** as the project's Developer Mandala. The technical/economic stage described as “Developer Mandala” is therefore substantially implemented already: the current Support Mandala is the first paid Mandala, consumes `pix`, uses the server-authoritative paid-cell flow, and is the current test object for the project's own economic model. The name “Developer Mandala” remains in the historical roadmap because it describes the economic role rather than a separate future product object. No additional standalone Developer Mandala needs to be created before moving to the next product experiments. The Alpha.45 10×10 experiment established that the visual Mandala remains usable for selecting cells, but permanent participant/message text inside cells does not scale well enough for larger grids. The next UX work should therefore separate the Mandala visual layer from readable participant/message information before increasing cell counts further. #### P0.5c Developer Mandala — first paid Mandala — implemented as Мандала поддержки The Developer Mandala roadmap stage is substantially implemented by the existing **Мандала поддержки**. It is the first paid Mandala and the current consumer of the project's internal `pix` economy. No separate Developer Mandala implementation is required at this stage. Future work may refine the economic/proceeds model if the project requires it, but the roadmap should not treat “Developer Mandala” as an additional product object that blocks launch-oriented product expansion. Initial configuration: - one fragment; - payment required for cell participation; - funds from this Mandala accrue to the project/developer; - architecture must allow the Mandala to grow to multiple fragments later. This Mandala becomes the first real consumer of the pix economy and the end-to-end payment test target. Required acceptance path: ```text Telegram user ↓ Stars ↓ pix ↓ Developer Mandala ↓ pix spent for a cell ↓ project/developer proceeds recorded server-side ``` The Sandbox remains free and continues to be the default introductory Mandala. #### P0.5d Mandala identity and sharing foundation As soon as multiple Mandalas exist, each Mandala should have a stable public identity and shareable entry point. Target model: ```text DigiDala ├─ Sandbox ├─ Developer Mandala ├─ Creator Mandala #... └─ Event Mandala #... ``` Each Mandala should have: - a stable identifier; - a shareable Mini App/deep-link entry; - a human-readable name for bot-menu presentation. The bot should eventually expose Mandalas as named buttons, while users can also share an individual Mandala link directly. This does not require the full Creator platform yet; it establishes the identity and routing foundation needed before multiple real Mandalas are launched. ### P0.6 Creator Mandala — user-owned Mandalas **Later product stage, after Stars → pix and the Developer Mandala are stable.** The intended MVP flow is: ```text Creator ↓ buys the right to create a Mandala via the bot ↓ Stars ↓ bot requests the Mandala image/configuration ↓ Mandala is created ↓ participants spend pix in its cells ↓ creator is the economic beneficiary of that Mandala ``` The purchase price should depend on the configured number of fragments/cells and the fragment price. Example target scenario: ```text 100 Stars → right to create a 20-cell Mandala ``` The creator/owner relationship and proceeds must be stored server-side and must remain independent from the participant identity of users filling cells. This stage should not be implemented before the underlying payment, pix ledger, Mandala ownership and Mandala identity foundations are stable. ### P0.7 Launch / Event Mandala A special Mandala dedicated to the project launch remains a later product mode. Its exact mechanics, ownership and economic treatment are intentionally not fixed yet. Do not block the payment/economy MVP on the event design. ### P0.8 Minimal moderation / audit foundation **Alpha.50.9.4–50.9.5 foundation implemented; QA hardening remains open.** The MVP moderation workflow now covers: - user complaints against occupied-cell content; - user complaints against the collective Mandala visual; - report reasons including an inappropriate pattern / color combination; - Telegram moderator actions for hiding a name, message, cell content or whole Mandala visual; - user blocking/unblocking; - complaint dismissal and restoration of moderation decisions; - cycle-bound moderation for cell content and Mandala visuals so late actions do not affect a later Mandala cycle; - preservation of participation, ownership, payment and historical occupation records; - public replacement of moderated content with neutral moderation text/state. The moderation model is intentionally about **public visibility**, not about deleting participation history, freeing occupied cells or changing payment records. Current QA follow-ups: 1. **Quarantined Mandala visual presentation.** The current UI can still expose the underlying artwork as a darkened/desaturated layer. The target state is a neutral visual area with an explicit moderation notice inside that area. 2. **Active-client synchronization.** Moderation changes currently become visible in an already-open Mini App only after manual refresh/restart. The target is automatic propagation without manual reload, preferably by extending the existing server-state synchronization/polling path. A new realtime transport such as SSE/WebSocket should be considered only if the existing synchronization model cannot provide the required behavior reliably. These two items are launch-readiness QA for moderation and should be resolved before treating the moderation foundation as fully verified. --- ## 4. Future product roadmap These directions are intentionally deferred until the P0 core is stable. ### Product modes - Sandbox — completed default introductory Mandala - Developer / DigiDala — first paid Mandala for project funding - Creator — user-owned Mandalas - Event — special launch/event Mandalas - Public - Charity - Community - Sponsor - Challenge - Memorial ### Participant and archive evolution - participant history / "My DigiDala"; - post-destruction participant legacy; - numbered historical objects; - richer archive and collection mechanics. ### Completion and event mechanics - Last Pixel / Destroyer role; - dynamic or premium final cells; - richer completion ritual; - scheduled/event-oriented DigiDala objects; - streamer/event scenarios. ### Expanded platform directions - charity campaigns; - teams and social relationships; - branded/sponsored areas; - alternative geometries; - creator platform and integrations. ### Rare / experimental states - preservation instead of destruction / immutable DigiDala; - exceptional historical artifacts. These ideas are product directions, not current MVP commitments. --- ## 5. Current product sequence The agreed launch-oriented sequence is now: ```text 1. Sandbox — complete ↓ 2. Stars payment foundation — implemented ↓ 3. pix / pixcoin economy + ledger — implemented and hardened ↓ 4. Developer Mandala = existing Мандала поддержки — substantially implemented ↓ 5. Large Creative Mandala (20×20 / 400 cells) ↓ 6. Daughter's fundraising Mandala with preserved source artwork in archive ↓ 7. Competitive Mandala — implemented and refined; final lifecycle QA remains open ↓ 8. RU/EN localization — implemented and manually verified through Alpha.50.9.2 ↓ 9. Telegram channel/group, final explanatory copy and launch preparation ↓ 10. Launch and subsequent product expansion based on real usage ``` The Sandbox is complete for its intended purpose and should remain free. The Developer Mandala stage is not a separate future implementation: for roadmap purposes it is the existing **Мандала поддержки**, which already consumes `pix` for paid cell participation and has the required economic test path. The sequence intentionally moves several product experiments ahead of the older Creator/Event ordering so the project can reach a public-launch shape sooner. This is an explicit planning deviation from the historical roadmap, not a rewrite of its original intent. --- ## 5.1 Current launch-sequence checkpoint — 2026-10-02 Alpha.49.7 closed the paid-cell synchronization defect; Alpha.50.1 completed the current Creative visual-cell UX checkpoint; Alpha.50.2 established the agreed 1:1 Pix/Stars economy; Alpha.50.4 closed the Alpha.50.3 release-gating UX defects; Alpha.50.5–50.5.9 completed and verified the first Особая мандала / Daughter campaign path including archive traces and manual end-to-end QA; Alpha.50.6–50.6.8 introduced and refined Competitive Mandalas, bot administration, navigation reliability, Telegram sharing and campaign archive navigation; Alpha.50.9 completed RU/EN Mini App localization; Alpha.50.9.1–50.9.2 completed and verified Telegram bot localization, persistent language preference, localized bot content and immediate RU↔EN switching. Alpha.50.9.4–50.9.5 added and manually exercised post-moderation; moderation remains in QA hardening. The important roadmap clarification is: > **Developer Mandala = the existing Мандала поддержки.** The Support Mandala already fulfills the role of the first paid/project-benefiting Mandala for the internal `pix` economy. It should therefore be treated as the implemented Developer-Mandala stage rather than as a separate future object. The next product sequence is: ```text Alpha.50.1 verified ↓ Alpha.50.2 verified · 1 Star = 1 Pix + current cell prices ↓ Alpha.50.3 deployed · manual QA found price API + purchase-row UX defects ↓ Alpha.50.4 verified · price API + purchase-row layout defects closed ↓ Alpha.50.5–50.5.4 verified · Особые мандалы / `campaigns` foundation + destruction-preview repair ↓ Alpha.50.5.7–50.5.9 verified · participant archive traces + Daughter copy/progress refinement + full manual QA ↓ Alpha.50.6–50.6.6 verified · bot administration + Competitive Mandala + navigation reliability; Alpha.50.6.7 verified Telegram share links; Alpha.50.6.8 deployed with initial manual QA passed; final Competitive lifecycle QA remains open ↓ UI/design cleanup + Russian/English localization ↓ Telegram community/channel + final product copy ↓ Launch ``` Stable Mandala identity, slug routing, shareable start links and navigation are already available and can be reused by these product modes rather than rebuilt. ### P0.3b Alpha.50.6–50.6.8 — bot administration, Competitive Mandala, navigation reliability, Telegram sharing and archive navigation Alpha.50.6 introduced the first content-managed Competitive Mandala mode by extending the existing `campaigns` architecture rather than introducing a parallel campaign system. Alpha.50.6.1 refined synchronization status, configurable pricing, editing, navigation and visual separation; Alpha.50.6.4–50.6.5 added controlled field sizes and fixed queued-campaign creation; Alpha.50.6.6 stabilized left/right navigation between ordinary, Special and Competitive spaces; Alpha.50.6.7 stabilized share-link generation through Telegram Main Mini App deep links; Alpha.50.6.8 added the permanent campaign archive index, navigable empty campaign spaces, circular campaign-space navigation and generation-specific artwork URL versions. The implemented product model is: - two competing images, not persistent teams; - 20×20 / 400 cells; - 200 cells per image side; - administrator-defined Pix price per cell; - one cell per Telegram user per cycle; - the user chooses the side/image directly; - the first side to occupy all 200 of its cells wins; - two separate 1024×2048 PNG files form the 2048×2048 square; - free cells retain the existing Sandbox/Support grayscale SVG marker; - archive reuses the campaign trace model, with the winner in color and the loser in grayscale; - queued campaigns can be prepared through the existing Telegram bot and the next queued campaign activates automatically after archive. The same stage introduced release-independent content administration for `@PixDala_bot`: private-chat-only admin access, administrator roles, editable welcome/about messages, and bot-driven creation/queue management of competitive campaigns. New content after deployment should not require a code release. Alpha.50.6.8 passed 84/84 automated checks and was deployed from the exact tag `v0.4.0-alpha.50.6.8`. Initial manual Telegram QA passed for the permanent Archive entry/index, empty Special/Competitive navigation, circular left/right traversal and the previously affected Competitive artwork-cache case. Two Competitive campaigns were created for queued-lifecycle verification. The only remaining manual verification item is the complete competitive lifecycle through winner determination, destruction, archive and automatic activation of the next queued campaign. ### P0.3c Localization release — Russian / English interface, campaign content and policy text The localization stage is not limited to translating a fixed set of Mini App strings. It is a separate release scope for making the product consistently multilingual while keeping mechanics, payment, navigation, Mandala lifecycle and server-authoritative behavior unchanged. The localization release must include: - a centralized Mini App i18n layer for RU/EN with English fallback and automatic selection from Telegram language, plus a persistent manual language override; - localization of all approved user-facing Mini App copy, including dynamic states, dialogs, errors, accessibility labels and empty/archive screens; - a compact language selector in the Mini App, with the architecture prepared for additional locales without rewriting application logic; - separation of Mandala mechanics from localized content: campaign identity/mechanics remain language-neutral, while title/description and other creator-supplied presentation fields are stored per locale; - bot-driven campaign creation that collects localized title/description content for the supported locales, with a defined English fallback where applicable; - preservation of historical localized campaign text in the archive so later edits to an active campaign do not rewrite already archived history; - localization of Terms, rules, reporting/help text and payment-support wording; moderation policy text must explicitly distinguish content removed or cells released for rule violations from legitimate Telegram payment/refund and support cases; - a localization QA pass covering locale detection, manual switching, fallback behavior, dynamic campaign text, archive presentation, bot-created campaigns and all approved RU/EN copy. The moderation tooling itself remains a separate implementation stage unless explicitly pulled into the localization release. The localization release must, however, establish the multilingual policy and moderation wording it will use. No functional behavior should be changed solely to complete this localization stage. ### P0.3c status — completed through Alpha.50.9.2 The RU/EN localization release scope is now implemented and manually verified across the Mini App and Telegram bot. Alpha.50.9.1 delivered the bot localization foundation; Alpha.50.9.2 closed the follow-up Telegram QA defects in welcome formatting and immediate language switching. No additional localization release-gate remains open at this checkpoint. ## 6. Planning and documentation rules `ROADMAP.md` is the source of truth for project direction and ordering. Before starting each substantial development stage: 1. review `docs/ROADMAP.md`; 2. compare the intended work with `docs/PROJECT_STATE.md`; 3. check durable architectural constraints in `docs/PROJECT_CONTEXT.md` and relevant ADRs; 4. inspect the actual active release/source when the task is code-related. After completing a substantial stage: - update `docs/PROJECT_STATE.md`; - update `docs/PROJECT_CONTEXT.md` when the durable checkpoint or architecture-level understanding changes; - update `docs/CHANGELOG.md` when the change belongs to a release. Do not silently rewrite historical intent. When the current plan diverges from the original roadmap, record the reason and preserve the historical stage. ### P0.1a.1 Bot module-format and rollback hardening — alpha.36.1 The first release-managed bot migration exposed a CommonJS/ESM mismatch under the repository's `"type": "module"` setting. The bot is therefore stored as `.cjs`, and the deployment rollback keeps a fallback to the preserved legacy systemd unit for the first migration release. --- ## 2026-09-08 — Alpha.42 completion checkpoint Alpha.42 completed the migration from the former Telegram test-bot naming to the main `@PixDala_bot` naming while keeping the existing test Mini App URL. The release-managed bot is now `bot/bot.cjs` with `infra/systemd/pixdala-bot.service`; the legacy test-bot unit remains only for rollback compatibility. Deployment rollback was hardened so a rollback to a pre-migration release can restore the legacy unit without leaving both bot services active. Alpha.42 passed the full automated check (35/35), tagged deployment, and manual Telegram QA. The Mini App/API token mismatch observed immediately after the token migration was resolved by restarting the API service; no code change was required for that runtime issue. The project is now ready to continue with **P0.5a Telegram Stars payment foundation**. The Sandbox remains deliberately free. The first payment milestone should be a minimal 1-Star test payment with server-side verification, success/failure/cancellation handling, idempotency, Telegram-user association and durable payment record; pix conversion/ledger work starts only after that foundation is proven. --- ## 2026-09-09 — Alpha.43 completion checkpoint Alpha.43 completes the public rename from PixDala to DigiDala. The change is intentionally limited to public branding and user-facing text. The Telegram bot remains `@PixDala_bot`, and technical identifiers such as `pixdala-*` services, deployment scripts and `/opt/pixdala/...` paths remain unchanged. The release was deployed from the exact `v0.4.0-alpha.43` tag, passed 35/35 automated checks, and passed Telegram QA. The project is ready to continue with **P0.5a Telegram Stars payment foundation**. --- ## 2026-09-09 — Alpha.44 completion checkpoint Alpha.44 completes and verifies the initial P0.5a Telegram Stars payment foundation. The permanent bot action is `⭐ Поддержать проект`; it supports 1 / 5 / 10 / 25 / 50 / 100 Stars and creates a server-authoritative project-support payment record. The internal `pix` economy remains a separate future stage. The release was tagged as `v0.4.0-alpha.44`, deployed from the exact tag to `/opt/pixdala/releases/v0.4.0-alpha.44`, passed 41/41 automated checks, and passed manual Telegram QA with a real 1-Star payment confirmed in the active SQLite database. Next roadmap step: P0.5b internal `pix` / `pixcoin` ledger, preceded by payment reconciliation/recovery hardening as required for reliable production operation. --- ## 2026-09-09 — Alpha.45 capacity and UX checkpoint Alpha.45 is the first concrete multi-Mandala routing/capacity experiment. It introduced a stable `support` Mandala with 100 cells, direct slug routing and explicit navigation while preserving Sandbox as the default free Mandala. Automated verification: **48/48**. Exact-tag deployment: **passed**. Manual Telegram result: - occupation and destruction lifecycle: passed; - 10×10 cell targeting: usable; - current in-cell participant/message text: not sufficiently readable at 100 cells; - free-cell text `Пока свободно`: should be removed in favor of a minimal state marker; - Desktop synchronization: small propagation delay observed, consistent with current polling; no transport rewrite planned yet. ### Next UX task Design and then implement a separated information layer for participant name/message: the default Mandala view should stay visually clean, cell interaction should open a readable information presentation, and the post-destruction historical message view should be independent from cell-size text rendering. Only after this UX model is settled should the project consider substantially larger Mandala grids. The internal `pix` ledger remains a separate subsequent economic stage. ## 2026-09-11 — Alpha.46.6 completion checkpoint Alpha.46.6 closes the small transition artifact carried from the Alpha.46.5 multi-Mandala checkpoint. The legacy free-cell presentation was removed from both Mini App render paths and replaced by the existing minimal marker for all Mandalas. Automated verification: **48/48**. Exact-tag deployment: **passed**. Manual Telegram QA: **passed** repeated Sandbox/Support switching; the previous `Пока свободно` flash was not observed. The next UX task remains the separated information layer for participant name/message and the independent historical-message presentation. The internal `pix` / `pixcoin` ledger and payment reconciliation hardening remain subsequent economic work. --- ## 2026-10-03 — Production environment preparation The project now has a local production-infrastructure candidate for the transition from the single test runtime to separate staging and production environments. The existing staging environment remains unchanged at `im-test.bktis.ru` with `@PixDala_bot`. The production candidate targets `digidala.ru`, `@DigiDala_bot` and isolated runtime paths under `/opt/digidala`. DNS, HTTPS certificate issuance, production environment secrets and first production deployment remain pending infrastructure steps.