73 lines
3.3 KiB
Markdown
73 lines
3.3 KiB
Markdown
# `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.
|