# TECH блоки (`type=0`, `version=1`)

TECH-тип покрывает системные записи пользовательской цепочки. Все TECH DataItem имеют подписанный индексный тег:

```text
t=tech
```

`HEADER` является root TECH-линии. Следующие line-based TECH-события (`TECH_CREATE_CHANNEL`, `TECH_FORK`) образуют одну последовательность с `lineCode=0`, ссылкой на предыдущий TECH-событийный блок и sequence `1..N`.

## Подтипы

### `subType=0` — `HEADER_COMPAT`

Стартовый блок цепочки (`block #0`). Payload содержит tag `SHiNE`, login владельца и `initialBlockchainKey32`.

`initialBlockchainKey32` — public blockchain-signing key, которым был создан fork №1; это историческая точка происхождения. При последующих fork значение не меняется.

HEADER сам не хранит line-prefix, но является root TECH-линии.

### `subType=1` — `TECH_CREATE_CHANNEL`

Создание нового канала. Блок одновременно:

- является очередным шагом TECH-линии;
- является root нового канала;
- имеет `t=tech`;
- имеет `c=<canonical_channel_slug>`.

Начало body:

```text
[4]  lineCode = 0
[4]  prevTechBlockNumber
[32] prevTechBlockHash32
[4]  techSequence
```

Далее идут `channelName`, `channelDescription`, `channelType`, `channelTypeVersion` согласно формату CREATE_CHANNEL.

### `subType=2` — `TECH_FORK`

`TECH_FORK` фиксирует создание нового fork и является обычным следующим шагом TECH-линии.

#### `TECH_FORK` body (`version=1`)

Big-endian:

```text
[4]  lineCode = 0
[4]  prevTechBlockNumber
[32] prevTechBlockHash32
[4]  techSequence

[32] parentBlockchainKey
[4]  forkPointBlockNumber
[32] forkPointBlockHash32
[8]  forkPointTimestampMs
[4]  parentTipBlockNumber
[32] parentTipBlockHash32
[8]  parentTipTimestampMs
[4]  discardedBlocksCount
[1]  reasonCode
[2]  commentUtf8Length
[N]  comment UTF-8
```

- `prevTechBlockNumber` — глобальный blockNumber предыдущего TECH-события; если до fork не было CREATE_CHANNEL/FORK, это `HEADER #0`;
- `prevTechBlockHash32` — hash этого блока;
- `techSequence` — предыдущий TECH sequence + 1; первый TECH-событийный блок после HEADER имеет `1`.

Остальная fork-часть:

- `parentBlockchainKey[32]` — public key предыдущего fork;
- `forkPointBlockNumber[4]` — последний блок старой цепочки, сохранённый в новом fork;
- `forkPointBlockHash32[32]`;
- `forkPointTimestampMs[8]`;
- `parentTipBlockNumber[4]` — tip старой цепочки на момент начала ротации;
- `parentTipBlockHash32[32]`;
- `parentTipTimestampMs[8]`;
- `discardedBlocksCount[4] = parentTipBlockNumber - forkPointBlockNumber`;
- `reasonCode[1]`;
- `commentUtf8Length[2]`;
- `comment[N]` — максимум 1024 UTF-8 байт.

`reasonCode`:

- `1` — `ROUTINE_ROTATION`;
- `2` — `POSSIBLE_COMPROMISE`;
- `3` — `CONFIRMED_COMPROMISE_ROLLBACK`;
- `4` — `RECOVERY`.

Текущая схема ротации перепубликует выбранный префикс `0..forkPointBlockNumber` новым blockchain key и затем добавляет `TECH_FORK`. Перепубликованные Frame сохраняются байт-в-байт; внешняя ANS-104 owner/signature меняется. Новый blockchain key в body не дублируется: он определяется owner/signature нового DataItem.

## Серверная проверка TECH-линии

Для `TECH_CREATE_CHANNEL` и `TECH_FORK` сервер требует:

1. `lineCode=0`;
2. первый TECH-событийный блок ссылается на HEADER и имеет sequence `1`;
3. каждый следующий ссылается на фактический текущий хвост TECH-линии;
4. номер предыдущего блока, его hash и sequence должны совпадать точно.

Таким образом CREATE_CHANNEL и FORK образуют единый проверяемый технический позвоночник пользователя.