Initial project import

This commit is contained in:
2026-08-14 09:40:51 +03:00
parent 00040e5ce4
commit d7099bf80d
146 changed files with 30509 additions and 1055 deletions
@@ -0,0 +1,72 @@
# `upo_test` / `test2` saved-state experiment
## Scope
- Test base: `upo_test`
- Extension: `test2`
- Extension GUID: `fb26cf42-7609-11f1-828f-005056b0d483`
- Common form: `t_Форма`
- Form GUID: `77494708-43ea-4956-ac3c-199cfb035ad2`
- Independently manually edited form: `tt_Форма3`
- Form GUID: `99590008-addf-49fa-9ada-24962756d0cf`
These are experiment identifiers, not a universal hardcoded route.
## Follow-up cross-extension confirmation (2026-08-13)
The same logical-file protocol was exercised on a different extension and
object class:
- Extension: `фс_Отчеты`
- Extension GUID: `9b11f844-3d08-11f1-8287-005056b0d483`
- Object: `Report._ПоступлениеТовара`
- Object GUID: `c428f629-785a-4141-b038-f2192bb4580d`
- Guarded change: `//Пример - 3``//Тест - 3`
The active root was a hash-keyed `ConfigCAS` record, but decoding it exposed
the logical `O` / `O.0` map and the SHA-1 of each active payload. The adapter
created exactly `E__configinfo`, `E__O`, `E__O.0`, executed a public
`code.write` replacement and reread it. A controlled `apply_and_rollback`
passed before `apply_and_verify`. A human then confirmed `//Тест - 3` in the
Configurator extension editor.
This proves the canonical object-module overlay route for this observed
extension-root family. The implementation must retain the suffix of the exact
resolved BSL stream: a separately diagnosed production route for
`Report.УОП_ПечатьЦенниковАссортимента` resolves its manager module as `.2`,
not `.0`. This does not authorize a guessed suffix: the selected `O.S` entry
and its SHA-1 must be present in the decoded root map. Forms or an unknown
root that cannot be decoded into that exact logical map remain unproven.
## Outcomes
1. Writing a `.0` module alone made a comment visible after a reload but
failed activation with a hash-version error.
2. Pairing the module write with the matching `__configinfo` map update made
the comment activate into `ConfigCAS`; Configurator cleared
`ConfigCASSave` after successful application.
3. Building a complete three-file initial overlay while Configurator was
closed, then opening and applying it, succeeded for `change-10`.
4. A manual save in `tt_Форма3` produced a three-row pending overlay for that
form plus `__configinfo`. Incrementally adding `t_Форма` descriptor/module
while preserving the existing rows and map entries kept both edits.
5. A pending `__configinfo` map can point at a newer active module than an
earlier inspection of `ConfigCAS`; selecting the source through the pending
map avoids duplicate BSL comments.
## Failed paths retained as evidence
- Raw module-only write: invalid collection hash.
- Random service-atom bytes: licensing/crypto error.
- Treating the active module as authoritative while a pending map exists:
duplicate comment insertion.
- Assuming UI text means SQL save: the editor buffer can differ from
`ConfigCASSave`; verify SQL immediately after saving.
## Verification after every apply
1. `ConfigCASSave` for the extension becomes empty.
2. Extension root key in `_ExtensionsInfo`/`ConfigCAS` changes to the new
`__configinfo` SHA-1.
3. Active `ConfigCAS` contains the requested BSL text.
4. The active map points to the SHA-1 of the active module bytes.