# DigiDala — Alpha 50.6.1 Changeset

## Release identity

```text
Base: v0.4.0-alpha.50.6
Release: 0.4.0-alpha.50.6.1
Commit: 97df895
Tag: v0.4.0-alpha.50.6.1
Status: released, tagged and deployed
Date: 2026-09-19
```

## Trigger

Manual Telegram QA of the deployed Alpha 50.6 completed the first Competitive Mandala creation successfully, then exposed four follow-up issues.

### Observed issues

1. Competitive Mini App stayed at `Подключение…` instead of switching to `Синхронизировано`.
2. Competitive creation used a hard-coded 10 Pix cell price; administrators need to set the price during creation and edit it later before occupation.
3. Active Competitive Mandalas were absent from the existing left/right Mandala navigation.
4. The 20×20 field had no visible center boundary while both artworks remained hidden, making the two support halves unclear.

## Implemented fixes

### 1. Competitive synchronization status

After the competitive API snapshot is successfully applied, the client now explicitly enters the ready state and updates the shared API status indicator. Existing ordinary Mandala loading logic remains unchanged.

### 2. Administrator-defined cell price and editing

The creation flow is now:

```text
left artwork
→ right artwork
→ price in Pix
→ description
→ preview
→ confirm
```

The new command is:

```text
/competitive_edit <slug>
```

It allows editing:

- cell price;
- description.

Price changes are rejected after the first cell is occupied. Description changes remain allowed.

### 3. Navigation

The active Competitive Mandala is added to the navigation-only list returned for Mini App arrows. It remains excluded from the regular cyclic catalog, so this does not turn a competitive campaign into an ordinary catalog Mandala.

### 4. Center divider

A vertical divider is applied only when the Mini App is in competitive mode. It is positioned between columns 10 and 11 of the 20-column field and does not modify the rendering of other Mandala types.

## Regression protection

The changes include backend/API integration assertions that:

- competitive campaigns appear in navigation-only results;
- competitive campaigns remain outside the regular cyclic catalog;
- competitive editing works before occupation;
- competitive price changes are locked after occupation;
- competitive creation does not remove Sandbox or Support from navigation.

All competitive-specific visual state uses an explicit competitive-mode class; existing modes do not receive the divider.

The functional QA rule remains strict: Telegram/Mini App behavior was accepted only after the exact release tag was deployed to the VPS.

## Automated verification

```text
Structure: OK
JavaScript syntax: OK
Unit: 10/10
Integration: 44/44
API: 17/17
Total: 71/71
```

The exact tag `v0.4.0-alpha.50.6.1` was committed, pushed and deployed successfully.
The VPS release is `/opt/pixdala/releases/v0.4.0-alpha.50.6.1`.

## Manual Telegram QA

Passed:

1. Direct Competitive launch and successful synchronization to `Синхронизировано`.
2. Left/right navigation into Competitive and back to adjacent existing Mandalas.
3. Competitive creation with an administrator-defined non-default Pix price.
4. Competitive price displayed correctly in the queue and Mini App.
5. Competitive description editing.
6. Price editing before the first occupied cell.
7. Price-change rejection after occupation while description editing remains available.
8. Visible center divider between the 10 left and 10 right columns.
9. Cell occupation on both Competitive sides.
10. Regression spot-checks of Sandbox, Small Creative, Large Creative, Support and Daughter/Special behavior.
11. Mobile Telegram and Telegram Desktop functional QA.

During Desktop QA, one transient direct-launch case loaded `app.js?v=0.4.0-alpha.50.6` instead of `v0.4.0-alpha.50.6.1`. The condition later disappeared and could not be reproduced, so no code change was made for it.

## Remaining manual QA

The only remaining release verification item is the complete Competitive lifecycle:

```text
one side reaches 200 occupied cells
→ winner_side
→ destroying
→ archived
→ next queued Competitive becomes active
```

This final end-to-end lifecycle test has not yet been completed.

The release is therefore considered **deployed and almost fully manually verified**, with only the final Competitive lifecycle scenario still open.