llm/docs/runbooks/1c-moxel-discovery.md

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.json contains inferred decoder rules from marker matrices and history diffs.
• reports/1c-template-baselines/Primer3_moxel_property_experiments.json contains one-property experiment analysis and the next probe plan.
• reports/1c-template-baselines/Primer3_moxel_property_experiments.manifest.json maps 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.json
• reports/1c-template-baselines/moxel-discovery-pipeline.md
• reports/1c-template-probes/latest-live-probe.json when --capture-live is used
• reports/1c-template-baselines/moxel-named-range-rules.md
• reports/1c-template-baselines/moxel-next-experiments.md
• reports/1c-template-baselines/moxel-next-action.json
• reports/1c-template-baselines/moxel-next-action.md
• reports/1c-template-baselines/moxel-next-action-check.json
• reports/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.json
• reports/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/used 75x26, 961 cells, 196 text values, 77 parameters, 108 merges, 233 distinct format indexes.
• ПФ_MXL_АвансовыйОтчетВВалюте: capacity/used 72x26, 938 cells, 188 text values, 75 parameters, 101 merges, 233 distinct 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.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.