15 KiB
1C MOXCEL Discovery
This runbook describes the read-only discovery loop for tabular document MOXCEL payloads.
Current Artifacts
reports/1c-template-baselines/Primer3_moxel_schema_discovery.jsoncontains inferred decoder rules from marker matrices and history diffs.reports/1c-template-baselines/Primer3_moxel_property_experiments.jsoncontains one-property experiment analysis and the next probe plan.reports/1c-template-baselines/Primer3_moxel_property_experiments.manifest.jsonmaps existing before/after summaries to property experiment labels.
Schema Discovery
Run marker/history discovery:
python scripts/discover_1c_moxel_schema.py `
--marker-matrix reports/1c-template-baselines/Primer3_marker_matrix_2026-06-27_latest.json `
--history-matrix reports/1c-template-baselines/Primer3_history_matrix.json `
--property-candidates reports/1c-template-baselines/Primer3_property_candidates.json `
--output-json reports/1c-template-baselines/Primer3_moxel_schema_discovery.json `
--output-markdown reports/1c-template-baselines/Primer3_moxel_schema_discovery.md
The current strongest rule is:
moxel.inline_text_cell.column:
one_based_column = int(last_numeric(preceding_scalars)) + 1
Named range coordinates are partially proven from controlled moves:
left/right: raw scalar indexes 2 and 4
top/bottom: raw scalar indexes 3 and 5
one_based = raw + 1
Use multi-cell and rectangular named ranges to split left from right and
top from bottom.
Build the stable registry after discovery:
python scripts/build_1c_moxel_schema_registry.py `
--discovery reports/1c-template-probes/upo_test_auto_moxel_schema_discovery.json `
--discovery reports/1c-template-baselines/Primer3_moxel_schema_discovery.json `
--output-json plugins/1c/metadata/moxel-schema-registry.json `
--output-markdown reports/1c-template-baselines/moxel-schema-registry.md
Validate the registry safety contract:
python scripts/check_1c_moxel_schema_registry.py `
--registry plugins/1c/metadata/moxel-schema-registry.json `
--output reports/1c-template-baselines/moxel-schema-registry-check.json
The registry allows read-side decoder rules only. Write-side MOXCEL mutation is kept blocked until a disposable-base round-trip proves the exact scalar path.
Verify registry rules against concrete probe snapshots:
python scripts/verify_1c_moxel_schema_registry.py `
--registry plugins/1c/metadata/moxel-schema-registry.json `
--probe reports/1c-template-probes/upo_test_auto_20260627T142419Z_670780b4.json `
--output reports/1c-template-baselines/moxel-schema-registry-verification.json
This check is data-backed: verified_read rules must pass on the supplied
probe snapshots, while candidate_read rules are reported as diagnostic
evidence and are not promoted automatically.
Full Pipeline
After a new probe or one-property experiment has been captured, refresh all MOXCEL discovery artifacts with one command:
python scripts/run_1c_moxel_discovery_pipeline.py
To capture the latest live MOXCEL probe first and then refresh all artifacts:
python scripts/run_1c_moxel_discovery_pipeline.py --capture-live --label pipeline-live
The pipeline runs schema discovery, named-range rule analysis, property experiment analysis, registry build, registry safety check, registry verification, and the next experiment plan. It writes:
reports/1c-template-baselines/moxel-discovery-pipeline.jsonreports/1c-template-baselines/moxel-discovery-pipeline.mdreports/1c-template-probes/latest-live-probe.jsonwhen--capture-liveis usedreports/1c-template-baselines/moxel-named-range-rules.mdreports/1c-template-baselines/moxel-next-experiments.mdreports/1c-template-baselines/moxel-next-action.jsonreports/1c-template-baselines/moxel-next-action.mdreports/1c-template-baselines/moxel-next-action-check.jsonreports/1c-template-baselines/moxel-status.md
When moxel-named-range-rules.json contains high-confidence rectangular range
evidence, the registry build step automatically promotes the corresponding
named-range read rules from candidate_read to verified_read. Write status
still remains blocked until a separate round-trip proof exists.
Property Experiments
Generate or refresh the property probe plan:
python scripts/analyze_1c_moxel_property_experiments.py `
--emit-default-plan `
--output-json reports/1c-template-baselines/Primer3_moxel_property_experiments.json `
--output-markdown reports/1c-template-baselines/Primer3_moxel_property_experiments.md
Analyze existing before/after experiments:
python scripts/analyze_1c_moxel_property_experiments.py `
--manifest reports/1c-template-baselines/Primer3_moxel_property_experiments.manifest.json `
--emit-default-plan `
--output-json reports/1c-template-baselines/Primer3_moxel_property_experiments.json `
--output-markdown reports/1c-template-baselines/Primer3_moxel_property_experiments.md
Each new experiment should change exactly one property on the same tracked cell
or range, then capture a fresh templates.map/summary snapshot.
To capture the next manual one-property save automatically, start the watcher before changing and saving the template in 1C:
python scripts/watch_1c_moxel_property_experiment.py `
--property ВертикальноеПоложение `
--target-text "Ячейка 7 - 2" `
--target-name R7C2_TEST `
--timeout-seconds 600 `
--run-pipeline-after
The watcher captures a before snapshot, waits for a new latest MOXCEL payload,
captures after, writes Markdown/JSON snapshots to
reports/1c-template-probes, and appends the experiment to
reports/1c-template-baselines/Primer3_moxel_property_experiments.manifest.json.
With --run-pipeline-after, it also refreshes schema discovery, property
analysis, registry build/check/verify, and the next experiment plan.
Prioritize:
ГоризонтальноеПоложениеВертикальноеПоложениеЦветТекстаЦветФонаШрифт.ИмяШрифт.Размер- borders
ЗащитаГиперссылка- wrapping
- column width
- row height
- merge ranges
Only promote a property path into write support after a disposable-base round-trip proves that changing that scalar affects only the intended property.
XML-Assisted Fixture Plan
Use XML exports only as analysis fixtures. The adapter runtime stays SQL-only:
it reads Config/ConfigCAS payloads, while exported Ext/Template.xml
files are used to label and verify decoder hypotheses.
Create a small extension with controlled templates and export it to XML after each controlled save:
- one tabular document with sparse text cells, direct parameters, placeholders, and empty formatted cells;
- one tabular document with horizontal, vertical, and rectangular merged cells;
- one tabular document with named areas and named ranges, including duplicate names in different positions;
- one tabular document dedicated to format changes: column width, row height, horizontal/vertical alignment, border, font, text color, background color, protection, wrapping;
- one fixture per non-tabular template type where possible: text document, binary data, HTML document, graphical/geographical schema, data composition schema, data composition appearance template, external component.
The concrete merge fixture checklist is stored in:
reports/1c-template-baselines/moxel-controlled-merge-fixtures.jsonreports/1c-template-baselines/moxel-controlled-merge-fixtures.md
Start with the merge fixtures MOXEL_Merge_None_Grid,
MOXEL_Merge_H_R5C18_W3, MOXEL_Merge_H_R6C2_W15,
MOXEL_Merge_V_R5C2_H3, MOXEL_Merge_Rect_R5C2_R7C4, and
MOXEL_Merge_Mixed_4Ranges. They are designed to split column edges, row
edges, width/height, and merge-record ordering without relying on the large
production print forms.
For MOXCEL discovery, change exactly one property per save, capture the SQL payload, then compare it with the exported XML shape. Promote read rules only when the SQL decoder can reproduce XML-visible facts from SQL bytes alone.
Use scripts/analyze_1c_template_xml_profiles.py to build XML fixture
profiles without feeding XML into the adapter runtime. Example:
python scripts\analyze_1c_template_xml_profiles.py `
--root "Z:\codex\1C\XML\UPO\Структура базы 1с\Конфигурация\Documents\АвансовыйОтчет" `
--output-json reports\1c-template-baselines\xml-template-profiles-avansovy-otchet.json `
--output-markdown reports\1c-template-baselines\xml-template-profiles-avansovy-otchet.md
Current АвансовыйОтчет XML fixture facts:
ПФ_MXL_АвансовыйОтчет: capacity/used75x26,961cells,196text values,77parameters,108merges,233distinct format indexes.ПФ_MXL_АвансовыйОтчетВВалюте: capacity/used72x26,938cells,188text values,75parameters,101merges,233distinct format indexes.
The SQL decoder should eventually reproduce these facts from SQL payloads:
capacity_dimensions/used_dimensions, coordinate-bound cell text and
parameters, authoritative merged_ranges, and format indexes/styles. XML
profiles are evidence for decoder hypotheses, not an input source for adapter
answers.
Compare the SQL-decoded baseline with the XML fixture profile after decoder changes:
python scripts\profile_1c_tabular_templates.py `
--adapter-url http://docker-gpu.cin.su:8011 `
--base-id upo_test `
--inventory-json reports\1c-template-baselines\upo_test_configuration_tabular_templates.json `
--output-json reports\1c-template-baselines\upo_test_tabular_template_profiles.json `
--output-markdown reports\1c-template-baselines\upo_test_tabular_template_profiles.md
python scripts\compare_1c_template_sql_xml_profiles.py `
--sql-profile reports\1c-template-baselines\upo_test_tabular_template_profiles.json `
--xml-profile reports\1c-template-baselines\xml-template-profiles-avansovy-otchet.json `
--output-json reports\1c-template-baselines\sql-xml-template-profile-compare-avansovy-otchet.json `
--output-markdown reports\1c-template-baselines\sql-xml-template-profile-compare-avansovy-otchet.md
The current comparison intentionally reports gaps for both АвансовыйОтчет
templates. SQL capacity still reports the MOXCEL allocation 128x72, while XML
spreadsheet dimensions are 75x26/72x26. With template_part_moxel_v8,
hint-aware SQL used_dimensions improved to 74x25 and 71x25; the remaining
edge likely depends on merge/format records. Limited cell/parameter counts,
missing authoritative merged_ranges, and missing format index coverage remain
open. Use these gaps as the next decoder scorecard; a gap should only disappear
when SQL bytes alone reproduce the XML-visible fact.
The compare report also shows Progress signals. A non-zero
cell_coordinate_hints_available signal means the SQL decoder recovered
coordinate evidence from hints, but the cells_missing_or_limited gap stays
open until authoritative cell rows/columns are decoded.
For merge-block row/size reverse engineering, regenerate the row-band report:
python scripts\analyze_1c_moxel_merge_row_bands.py `
--template ПФ_MXL_АвансовыйОтчет `
--template ПФ_MXL_АвансовыйОтчетВВалюте `
--output-json reports\1c-template-baselines\moxel-merge-row-band-analysis-avansovy-otchet.json `
--output-markdown reports\1c-template-baselines\moxel-merge-row-band-analysis-avansovy-otchet.md
This report compares XML merge rows with SQL MOXCEL small-scalar bands and
packed scalar/32 column-edge evidence. Treat row_or_size_hints as low
confidence until a controlled merge fixture proves which scalar positions are
row indexes versus widths, heights, or flags.
merge_record_block_candidates[].evidence.record_analysis exposes a normalized
SQL-only view of the candidate block: per-record shape/head, packed
scalar/32 values, small scalars, scalar slot summaries, value-to-record runs,
and sample records. Use it for slot-formula discovery; it is diagnostic
evidence and does not make merged_ranges authoritative by itself.
To score candidate numeric slots against XML-visible merge fields, run:
python scripts\analyze_1c_moxel_merge_slot_candidates.py `
--template ПФ_MXL_АвансовыйОтчет `
--template ПФ_MXL_АвансовыйОтчетВВалюте `
--output-json reports\1c-template-baselines\moxel-merge-slot-candidates-avansovy-otchet.json `
--output-markdown reports\1c-template-baselines\moxel-merge-slot-candidates-avansovy-otchet.md
The current large-form slot report is intentionally hypothesis-only. It shows
that simple value-set and ordered-offset matching are dominated by low-entropy
height/flag values and do not prove a top/left/bottom/right formula. Use the
controlled merge fixtures before promoting any SQL rule into authoritative
merged_ranges.
Inline text style candidates expose coordinate_hints for the column using the
discovered rule
inline_text_column_from_last_preceding_scalar_plus_one. Treat this as a
high-confidence hint for analysis and controlled experiments, not as an
authoritative cell coordinate until row and merge rules are proven by SQL/XML
round trips.
The adapter and SQL profile reports include cell_style_coordinate_hints in
counts. Track this count separately from cells: it measures how much
coordinate evidence was recovered from inline style records, while cells
remains reserved for decoded row/cell runs with authoritative coordinates.
cell_coordinate_hints combines the style-derived column hint with a matched
decoded cell row when the text/cell id can be linked. Use it to inspect
text-to-coordinate evidence during decoder discovery. Do not count it as
authoritative cells coverage until the row rule and merge interactions are
validated against SQL/XML fixtures.
For compact inspection, request only coordinate evidence from templates.map
or templates.analyze with sections=coordinate_hints. This returns
cell_coordinate_hints and cell_style_coordinate_hints from both the
structure and analysis layers without dumping all cells/styles.
Coordinate hints, hint-aware used_dimensions, merge-record block candidates,
SQL-only merge-block column-edge hints, low-confidence row/size scalar hints,
and merge-block record_analysis changed the decoded artifact schema, so
MOXCEL template cache uses template_part_moxel_v9. Refresh SQL baselines after
deploying the new adapter; old v2/v3/v4 decoded artifacts will not contain
the current cell_coordinate_hints, merge-block evidence, and used-dimension
semantics.