# Doubao Journal Format

> 用于对学术论文类 Word/DOCX 文档进行期刊、学校、会议或课程要求的格式排版与修复。当用户需要把论文原稿套用.docx 模板或明确格式规则、或提到论文排版、期刊投稿格式、学位论文格式、会议论文模板、时使用；如果同一请求同时包含论文 Word 排版和任何非排版任务，必须先停止并询问用户选择“只做格式排版”还是“作为复合任务拆分处理”，在用户明确选择前不得执行排版。不用于论文写作、润色、降重、翻译、代写、文献检索、补引用、验证引用、伪造数据/引用，或普通非论文 Word 文档套模板；

- Skill: `ahang1598/doubao-journal-format` (Agent Skill, multi-file: 14 files)
- Install (CLI): `npx skillmds add ahang1598/doubao-journal-format`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ahang1598/doubao-journal-format/raw
- Safety review: pending (external: skill-scanner PASS, skillspector FAIL)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: ahang1598 (https://skillmd.com/u/ahang1598)
- Updated: 2026-08-19
- Page: https://skillmd.com/skills/ahang1598/doubao-journal-format

---


# DOCX Journal Format

Apply an academic journal DOCX template to a target DOCX without reconstructing the document through `python-docx`. The tool edits the OpenXML package directly and keeps body text, formulas, images, OLE objects, tables, and relationships in place.

## Trigger And Boundaries

Use this skill only when the user explicitly asks for paper formatting, journal formatting, Word formatting, document typesetting, applying a template format to a Word file, or reformatting a `.docx` according to another `.docx` or explicit formatting rules.

Before running any formatting tool, enforce these input boundaries in this exact order:

- Composite-request hard stop: this is the highest-priority boundary check and it runs before target-file, template, source-format, extraction, QA, or any other check. If the same user request contains academic Word/DOCX formatting plus any non-formatting demand, the whole request is temporarily blocked. Non-formatting demands include writing, rewriting, polishing, translation, plagiarism reduction, literature search, reference addition/completion, DOI lookup, citation/reference verification, content expansion, summary/abstract/conclusion rewriting, data/statistical changes, figure/table content recreation, or any request to create, improve, verify, or validate scholarly content. In this case, do not read files, inspect attachments, browse, search, extract text, run scripts, edit files, generate output documents, or continue the formatting route. Respond only with a concise clarification that names the non-formatting demand(s) and asks the user to choose:
  - `A. 只做 DOCX 格式排版：按用户已经提供的目标文档、内容和参考文献原样排版。`
  - `B. 这是复合任务：先拆分/处理非排版部分，之后再进入排版。`
  End the turn after asking. Continue only after the user explicitly chooses `A` or clearly says to ignore all non-formatting demands and do formatting only. If the user chooses `B`, do not use this skill to perform the non-formatting parts.
- Required target: the user must provide a target `.docx` file to be formatted. If no target `.docx` is provided, ask the user to upload the Word file that needs formatting.
- Required format source: accept explicit user formatting instructions, a valid Word `.docx` template/source-format file, or extractable formatting evidence from another source.
- Non-`.docx` source boundary: uploaded or linked format-source files that are not real `.docx` packages, including but not limited to `.pdf`, image files, website links, and legacy `.doc`/`.dot`, should not block the run by themselves. Extract explicit text formatting requirements first. If text rules are found, use them; if a property is missing, complete that property from the selected bundled fallback. If no text rule is found, use the selected standard fallback directly. Visual/geometry evidence from any non-`.docx` source may only choose `zh_single`, `zh_double`, `en_single`, or `en_double`; it must not define paragraph roles, alignment,字号/point size, fonts, bold/italic, color, underline, indentation, spacing, tabs, headers/footers, support files, or run-level style. Record that the source is weaker than a native `.docx` template and include the standard-fallback risk in the final notes.
- Text-rule priority boundary: do not confuse weak source type with weak text rules. A PDF/website/image/OCR/DOC/DOT source is weaker than native `.docx` because it lacks Word XML style parts, but any explicit text rule extracted from it is authoritative for the exact properties it states. `user_rules` and extracted text rules must outrank bundled fallback. Fallback may fill only unstated, missing, or unsafe-default properties. In user-facing notes, never say or imply that an explicit website/PDF text rule was lower priority than fallback.
- Website/author-guide boundary: website pages such as Nature author formatting guides are text-rule evidence, not full Word/OpenXML templates, unless they provide an actual editable `.docx`/`.dotx` template. Use explicit prose rules from the page, for example `Contributions should be double-spaced`, but do not promise replication of the publisher's print/PDF house style. If the website does not provide exact Word font/size/spacing/page XML, final notes must say the result follows extracted submission rules plus the standard fallback and should be checked in Word.
- Global manuscript-rule boundary: prose that states manuscript-wide formatting without naming a role must still be mapped to relevant manuscript content roles. For example, `Contributions should be double-spaced and written in English` should set Word-compatible double spacing on abstract/summary, body, reference items, captions, and display equations unless a stronger role-specific rule conflicts.
- OOXML spacing boundary: Word line spacing must always be serialized as Word-compatible integer values. Never write `w:line="1.5"` or other decimal multiples into `styles.xml`, `document.xml`, `Normal`, or `docDefaults`; convert 1.5 line spacing to `w:line="360" w:lineRule="auto"`, double spacing to `480`, single spacing to `240`, and exact point spacing to points*20. Run spacing normalization before repack and record any repairs in QA.
- Rules JSON explicit-field boundary: a `rules.json` role rule with deterministic formatting keys such as `size`, `font_size`, `fonts`, `font`, `spacing`, `line_spacing`, `indent`, `paragraph.indentation`, `align`, `bold`, `italic`, `color`, `tabs`, or `numbering` is an explicit text/user rule even when it lacks `source` or `confidence`. Preserve these fields on non-DOCX routes and drop only true visual/geometry inference fields. Also accept OOXML-summary shaped user rules such as `summary.pPr.spacing.line`, `summary.pPr.spacing.lineRule`, `summary.rPr.sz.val`, `pPr.spacing`, and `rPr.sz`; normalize them into the same flat rule fields before sanitization, fallback merge, and style installation.
- Unified evidence route: every format source type must be distilled into the same role-based `style_spec.json` contract before target formatting. Native `.docx`/`.dotx`, converted `.doc`/`.dot`, PDF, image/OCR, website, and explicit text rules differ only in evidence priority and confidence; they must not use separate target-formatting logic after the style spec is built.
- Unified non-`.docx` route: all non-`.docx` format sources must use the conservative chain `explicit/user text rules -> extracted source text rules -> source column detection for fallback variant -> bundled OOXML fallback -> structural QA repair`. The target role map still identifies title, author, abstract, headings, captions, references, equations, and body from the target document, but non-`.docx` visual evidence must not define target role styles. Missing font/字号/alignment/spacing/indent/tabs/table/equation/reference properties come from `assets/fallback_ooxml_spec.json` unless explicit text rules lock them.
- Low-confidence visual evidence must not block granular fallback. If PDF/image/OCR/DOC/DOT evidence only shows the document is single-column or double-column, use that only to pick the fallback variant. For website links, use column evidence only when website/user text explicitly states the manuscript column count; otherwise default to single-column. If column count is not reliable, choose language fallback from explicit rules or target text and default to single-column.
- PDF column detection boundary: PDF auto column detection must be conservative but not page-vote-only. Do not classify a PDF as double-column from left-edge clusters alone, because single-column papers often contain first-line indents, hanging references, centered headings, equations, and captions. First try page-level balanced left/right body text bands with a clear gutter, enough right-column body-like lines, and little body text crossing the column boundary. If sample-issue pages have sparse prose because titles, formulas, figures, tables, or captions fragment the page, also run cross-page column-start aggregation: require stable left and right column starts across multiple pages, a real gutter between the left-column right edge and right-column start, low crossing-line ratio, and repeated pages containing both starts. If both page-level and aggregate evidence are weak, default to single-column and tell the user they can rerun with `--body-cols 2`/explicit column instructions when double-column was intended.
- Low-confidence column detection must still run for converted `.doc`/`.dot` sources. A converted `.docx` is not style/page/header authority, but its reliable `sectPr/w:cols` count and source filename keywords such as `双栏`, `单栏`, `two-column`, or `single-column` may choose the fallback variant. Do not hardcode converted `.doc`/`.dot` sources to single-column before checking this allowed column evidence.
- PDF/image/website/OCR coarse alignment can misread long front-matter lines as justified. Do not write visual-only alignment rules at all for non-`.docx` format sources; rely on explicit text rules or the selected fallback's default centered/left/justified alignment.
- PDF sample-issue boundary: if the user uploads or links a PDF sample issue, sample article, publisher proof, author instructions, submission guidelines, or PDF format instructions as the target-format source, use it only for text-rule extraction and fallback column selection. When possible, run `scripts/extract_pdf_format.py` to collect selectable PDF text first, then PDF geometry only for single/double-column fallback selection with PyMuPDF/fitz, pdfplumber, `pdftotext`, `pdffonts`, and `mutool`; use OCR only for scanned/image-only text rules. Do not use PDF visual inference for role style alignment,字号/point size, fonts, bold/italic, colors, underlines, indentation, exact line spacing, tab stops, headers/footers, support files, or run-level details. Record that the PDF may not expose reliable `styles.xml`, paragraph styles, numbering definitions, section breaks, table border XML, formula tab stops, object anchors, or header/footer relationships, and recommend either a `.docx` template/source-format file or explicit text formatting instructions in the final notes.
- Legacy `.doc`/`.dot` boundary: if any uploaded format-source Word file is `.doc` or `.dot` rather than `.docx`/`.dotx`, convert it to temporary `.docx` only so text can be extracted. Do not use converted `styles.xml`, converted `Normal`/`Heading`/bibliography shells, representative paragraph/run direct formatting, rendered visual crosscheck, converted settings/fontTable/theme, headers/footers, or converted page XML as style authority. If the converted text contains explicit format rules, use those property-level rules; if not, apply the selected standard fallback. If the converted or rendered source reliably exposes single-column/double-column layout, use only that column count to choose fallback. Record the `.doc`/`.dot` conversion risk in the final notes and recommend either a native `.docx`/`.dotx` template or explicit text formatting instructions.
- Column-layout conversion boundary: if the requested formatting or the template/target evidence indicates a single-column to multi-column conversion, multi-column to single-column conversion, or mixed-column layout migration, warn before formatting that images, tables, floating objects, formulas, captions, page breaks, section breaks, and object anchoring may not adapt cleanly after the column count changes. Recommend that the user provide explicit layout instructions, a clearer target-format source, or manual constraints such as where the body section starts and whether wide figures/tables should remain full width. Proceed only after this warning has been given; record the column-conversion risk in the final notes.
- Website-link boundary: if the user provides a website link as the target-format source, extract available website/text evidence first. If the website text or user instruction explicitly states single-column or double-column manuscript layout, record that as column evidence. If the website link does not explicitly say single-column or double-column, default to single-column. Do not infer double-column from Nature/Science-like publisher brands, published article pages, production PDFs displayed on the site, page screenshots, visual website layout, journal examples, or common publication practice. If format requirements embedded as images on a website are hard to extract reliably, record that risk and suggest screenshots of image-based formatting instructions in the final notes.
- Image/OCR boundary: if the user provides a screenshot or image as the target-format source, extract available text evidence first. Visual/image/screenshot inspection may only help decide single-column or double-column fallback when reliable; this image/OCR rule does not override the website-link default-single rule above.
- Universal visual-source boundary: for every non-DOCX visual source, including PDF, screenshot, image, OCR output, website, rendered DOC/DOT preview, or any externally supplied visual rules JSON, drop visual role/alignment/字号/font/bold/italic/color/underline/indent/spacing/tabs/reference-hanging/run-level fields before building `style_spec.json`. Retain only explicit text rules and optional column-count metadata for fallback selection.
- Blank/carrier template boundary: if a blank DOCX is used only as a carrier for text/PDF/image/website rules, or if the uploaded source package has no meaningful format text/sample content, treat it as `blank_carrier_template`. Choose Chinese/English fallback from explicit rules first and then from the target document text, not from the empty carrier package. Generate `docDefaults`, `Normal`, and every role style directly from explicit rules plus granular fallback. Do not let the blank Word package's default `Normal` font,字号, single line spacing `w:line="240"`, paragraph spacing, theme fonts, or built-in heading defaults become source evidence.
- Fallback mixed-column boundary: when a weak/non-`.docx`/blank-carrier source selects a double-column fallback, the fallback is not whole-document double column. Chinese and English double-column fallbacks must keep title, author, affiliation, metadata, abstract, keywords, and other front matter in a single-column front section, then insert a continuous section break before the target body start so only body/back matter receives the double-column section. If the target body start is unclear, keep the remaining single section single-column and warn instead of applying double columns to the whole document.
- Header/footer watermark boundary: target manuscripts may contain proof/sample watermarks as behind-text or large anchored images in `word/header*.xml` or `word/footer*.xml`. After page setup and before importing template headers/footers, remove only target image-only header/footer paragraphs that contain behind-text or large anchored drawings; preserve normal header/footer text, page numbers, journal names, fields, body images, and any later template-provided header/footer content. Record cleanup stats and warn the user to visually confirm watermark removal.
- High-inline-content spacing boundary: after styles, direct-format cleanup, equation tabs, table formatting, superscripts, and metadata repairs, scan paragraphs containing `w:drawing`, `w:pict`, `w:object`/OLE/MathType, or OMML. If their effective paragraph spacing is `w:lineRule="exact"` from either direct `pPr` or the assigned style, write a direct paragraph spacing override with `w:lineRule="auto"` so tall inline images/formulas/objects are not clipped. Do not change normal text-only body paragraphs and do not edit image/OLE/formula payloads.
- Chinese classification metadata layout boundary: whenever the target document explicitly contains `中图分类号` and `文献标志码` in the same paragraph or in adjacent metadata paragraphs, normalize only that pair into one paragraph with `中图分类号` at the left and a right-aligned tab stop before `文献标志码` at the body text boundary computed from page width and margins. Apply this deterministic repair for native `.docx` templates and weak/non-`.docx` fallback sources alike unless the user explicitly disables it or gives a conflicting instruction. Do not set this line as justified, do not rely on repeated spaces, and do not infer this rule for unrelated metadata.
- Native `.docx` instruction-template boundary: a native `.docx` can still be a prose/instruction template rather than a complete style template. If template text explicitly says a role's font/字号, such as `摘要：楷体小5号` or `文章正文是5号宋体`, but the representative paragraph/style lacks deterministic line spacing, indentation, paragraph spacing, or other core properties, complete only the missing properties from the selected granular fallback. Preserve the explicit text-rule font/字号. Do not apply whole-role fallback to clean native DOCX styles with trustworthy paragraph XML.
- Explicit postprocess boundary: the normal route is a formatter, not a general content editor. Content/structure edits such as moving tables/figures after references, changing body citation markers from `[1]` to `(1)`, converting reference-list prefixes from `[1]` to `(1)` or `1`, or rewriting figure/table caption prefixes may run only when the user or extracted source text clearly requires that exact manuscript operation. Do not enable these edits from template visual examples alone. When source prose rules clearly require the operation, write `postprocess_operations` into `rules.json`/`_meta`, let `format_docx.py` auto-generate the temporary explicit postprocess config, and run final QA after the postprocess. Use `--explicit-postprocess-json` only for a reviewed/manual override. For figure relocation, move only standalone figure blocks with clearly adjacent figure captions; skip OLE/MathType/OMML/formula objects, uncaptioned drawing/pict paragraphs, section-property paragraphs, and body-prose paragraphs that merely contain an anchored drawing.
- If neither explicit formatting instructions, a valid Word template, nor extractable formatting evidence is available, stop and ask the user to provide target formatting instructions or upload a `.docx` template/source-format file.
- If the user uploads unrelated images, website links, PDFs, screenshots, or other attachments and they do not contain extractable formatting requirements, do not infer a format. Ask the user to upload a correct `.docx` template or provide clear formatting instructions.
- PDFs, websites, images, screenshots, and legacy Word files may be used when they provide extractable formatting evidence, but they are weaker than a Word `.docx` template only as containers. Their explicit text rules still outrank fallback for stated properties. The final notes should recommend uploading a `.docx` source-format file or directly providing explicit text formatting rules for better accuracy, without saying that extracted text rules were ignored or demoted.
- Do not use Feishu/Lark documents as the final output format. The final deliverable must be a `.docx` file.
- Do not expose intermediate JSON files such as `style_spec.json`, `role_map.json`, or `superscript_map.json` as normal user-facing deliverables. Generate them internally for audit/debug only, unless the user explicitly asks for them.

If a boundary check fails, stop before editing files and ask for the missing input in one concise message.

Composite hard-stop examples:

- User asks: `帮我润色摘要、降重，然后按 Elsevier 模板排版。`
  Response must only say that the request mixes DOCX formatting with polishing/plagiarism-reduction, then ask the user to choose `A. 只做 DOCX 格式排版` or `B. 作为复合任务先拆分非排版部分`. Do not read or edit the document in that turn.
- User asks: `联网补 20 篇真实参考文献并统一排版。`
  Response must only say that the request mixes DOCX formatting with literature/reference acquisition, then ask the same A/B choice. Do not browse or format in that turn.
- User asks: `翻译成英文 SCI 风格后套 IEEE 模板。`
  Response must only say that translation/SCI rewriting is non-formatting work and ask the same A/B choice. Do not translate or format in that turn.

## User-Facing Output

When formatting succeeds, return only the final `.docx` as the main deliverable. In the final response:

- First, briefly say that formatting is complete.
- Do not describe successfully applied formatting, style-transfer details, granular fallback properties, or internal extraction decisions.
- Include only a short `需要特别确认` note when relevant. Mention concrete visual-check items from the internal report, such as non-`.docx` source risk, PDF/image/website visual-inference risk, legacy `.doc`/`.dot` conversion risk, single-column/multi-column layout changes, section-break position, images, tables, formulas, captions, floating objects, reference numbering/order, citation superscripts, author/affiliation superscripts, metadata/abstract/keywords, or publisher-specific details.
- If any format source was not a native `.docx`, say that the source container was interpreted through weaker evidence, but explicit text rules found in that source were applied first and only missing properties used fallback. Suggest either uploading a `.docx` template/source-format file next time or directly telling the assistant the formatting rules in text for more accurate extraction.
- Include a short `易出错提示` note. Keep it focused on likely visual risks and do not explain implementation details. If no special risk is known, say only that the user should open the Word file and visually confirm the final layout.
- Briefly mention that the user should open the Word file locally to confirm the visual result.
- Do not list or link intermediate JSON audit files unless explicitly requested.
- End with a sentence like: `如果有什么不对的地方，可以继续让我编辑。`
- Put the output `.docx` file link at the very bottom of the response, after all notes and after the closing sentence. Do not place any text below the output file link.

## Detailed Modules

Keep this main file as the route map. Load the detailed module only when its surface is reached by the request or by the mandatory route:

- `references/style-routing.md`: required for role-based style extraction, `style_spec.json`, `role_map.json`, prose text rules, generated role styles, and direct-format cleanup.
- `references/references-numbering-superscript.md`: required for `numbering.xml` migration, reference-list numbering repair, bibliography indentation/numbering, reference-citation superscripts, and author/affiliation superscripts.
- `references/equations-tables-sections.md`: required for equation tab-stop layout, formula/OLE handling, table body formatting, page setup, headers/footers, section routing, and single/multi-column layouts.
- `references/explicit-postprocess.md`: required only when the user clearly asks for post-format content/structure edits, including table/figure block relocation, body citation marker conversion, reference-list prefix conversion, caption prefix normalization, or caption first-sentence bolding.
- `references/preservation-rules.md`: required before any edit or repack step. These are non-negotiable preservation and final-output guardrails.
- `references/template-distill-render-qa.md`: required for template evidence contracts, PDF text-rule and column fallback extraction, `qa_report.json`, format-conformance QA with automatic repair, LibreOffice compatibility QA, table-geometry/image-anchor/field/heading QA, target-before/final render comparison QA, text-rule-source render-compare skip routing, regression visual diff, and final visual-risk notes.

Do not act from memory on a module surface. Read the corresponding reference file before applying that part of the workflow.

## Mandatory Route

Use this order for every formatting run:

1. Confirm the trigger and boundary checks above.
1a. Run the composite-request hard stop before every other action. If triggered, ask the A/B clarification question and stop the turn. Do not perform any other mandatory-route step in the same response.
2. Read `references/preservation-rules.md` before editing or repacking anything.
3. Detect non-`.docx` format-source inputs before extraction. This includes `.pdf`, images, website links, legacy `.doc`/`.dot`, and any other non-OpenXML source. Extract text rules first. Use visual/geometry tools only to detect reliable single-column/double-column fallback choice. For PDF column detection, treat left-edge clustering as insufficient by itself; require left/right body-band and gutter evidence, or cross-page stable column-start aggregation with low crossing ratio when sample pages are sparse. Mark the source as lower confidence, set `non_docx_standard_fallback`, and save the risk for the final notes.
4. Detect whether the non-`.docx` source is a PDF sample issue, sample article, publisher proof, author instructions, submission guidelines, or PDF format instructions. Read `references/template-distill-render-qa.md`; run `scripts/extract_pdf_format.py` when practical. Use generated `pdf_rules.json` as `--rules-json` and pass `--format-source-type text_rules` or rely on `_meta.source_type="text_rules"`. The PDF rules JSON must contain only explicit text style rules, explicit text-derived `postprocess_operations`, and `_meta.fallback_columns`/`source_column_detection`; it must not contain visual role/alignment/typography rules. Continue even when no explicit PDF text rule is extracted by applying the selected standard fallback and warning the user.
5. Detect legacy `.doc`/`.dot` Word inputs before zip validation. Convert them to a temporary `.docx` only to extract text and reliable column-count metadata. Route the converted source as `converted_docx_template`/text-only evidence; do not use converted style XML, direct formatting, headers/footers, support files, or page XML as style authority. Do inspect converted `sectPr/w:cols` and source filename keywords only to choose single-column or double-column fallback; if detection fails, default to single-column and record the reason.
6. Detect whether the request or Word evidence indicates single-column to multi-column, multi-column to single-column, or mixed-column migration. Warn about image/table/formula/caption/object/section risks before formatting and record the risk for final notes.
7. Detect whether the format source is a website link. Extract available website/text evidence, and if image-based instructions appear inaccessible, record the risk and suggest screenshots in the final notes. For website links only, use double-column fallback only when the website text or user instruction explicitly says the submitted manuscript should be double-column; otherwise default to single-column and record `website_unspecified_columns_default_single`. Stop only if the website yields no usable formatting evidence.
8. Validate both Word inputs are real `.docx` zip packages, unless the format source is explicit user text rules.
9. Extract template and target packages.
10. Read `references/template-distill-render-qa.md`, then run structural QA on the template and target-before documents when practical. Treat this as the evidence contract for section, style, direct-format, table geometry, image anchors, Word fields, heading hierarchy, object, and package-part preservation.
11. Read `references/style-routing.md`, then read template body text for prose formatting rules before style injection.
12. Lock the source-aware evidence priority before building styles. Native `.docx`/`.dotx`: `user_rules > template_text_rules > representative_template_direct_format > template_style_xml > property-level granular fallback only when template_text_rules are explicit and core properties are missing/default`. Do not apply whole-role fallback to clean native DOCX styles unless a table/equation-specific fallback is explicitly triggered. All non-`.docx` sources, including legacy `.doc`/`.dot`, PDF, image/OCR, website, screenshot, and externally supplied visual rules: `user_rules > extracted_text_rules > source_column_detection_for_fallback_variant > bundled_OOXML_fallback > legacy_dictionary_fallback`; for website links, the source-column step is allowed only when website/user text explicitly names the manuscript column count, otherwise it is `website_unspecified_columns_default_single`. Blank/carrier templates: `user_rules > extracted_text_rules > bundled_OOXML_fallback materialized into docDefaults/Normal/role styles`. The bundled fallback is `assets/fallback_ooxml_spec.json`, with four variants: Chinese single-column, Chinese double-column, English single-column, and English double-column. It stores role-level `pPr_xml/rPr_xml`, `Normal`, body baseline, table three-line `tblPr/tcPr`, equation paragraph baseline, section/column metadata, and Chinese bilingual caption policy. Old dictionary fallback is only an emergency missing-field backup after the OOXML fragment has been merged and must not override explicit native `.docx` text-rule channels. For every source type, re-apply explicit user/text rules after fallback merge so locked channels such as font, size, line spacing, indentation, numbering, or caption wording cannot be overwritten by fallback. Representative direct formatting remains allowed only for native DOCX style extraction; never promote first-run formatting as whole-role style. For non-`.docx` carriers, do not inherit Heading/Reference colors, underlines, borders, small caps, theme defaults, support files, headers/footers, or page XML unless explicit user/text rules require them; only allowed column evidence may affect fallback variant selection.
12a. Validate `rules.json` before style-spec construction. Record valid roles, invalid roles, normalized OOXML-summary fields, and ignored fields in `qa_report.format_source.rules_schema_diagnostics`. If a role has no recognized deterministic style keys after normalization, emit a clear schema warning instead of silently falling back. Normalize line-spacing aliases and decimals at this stage: `line_spacing: "1.5"`, `spacing.line: "1.5"`, `double-spaced`, and `single-spaced` must become legal Word `w:line` integers before they enter `style_spec.json`. A user rule that explicitly sets body line spacing must also update weak-source `Normal` and `docDefaults` body baselines so unbound/body-like paragraphs cannot revert to Word default `w:line="240"`.
12b. After style installation and before repack, scan `styles.xml`, `document.xml`, headers/footers, footnotes/endnotes, and other Word XML parts for invalid spacing values. If any `w:spacing/@w:line` is decimal or textual, repair it to Word-compatible integer twips/line-multiple values and write the repair count into `qa_report.format_source.spacing_value_normalization`.
13. Build an intermediate role style spec JSON from the template/evidence source only. The template evidence contract may feed `style_spec.json`; the target file must not. Store source type, original extension, conversion route, evidence priority, fallback language, fallback columns, fallback-column detection source, and low-confidence warnings in `style_spec._meta`/`qa_report.format_source` when available. When the format source is a blank/carrier package or weak external source, materialize the bundled OOXML fallback into `style_spec` before installation so `title`, `heading1`, `body`, `equation`, and other roles carry explicit fallback paragraph spacing/font/字号 rather than inheriting carrier defaults. Text/user rules merge at property level: for example, `正文宋体五号` locks CJK font and size while unspecified line spacing, Latin font, indentation, and alignment still come from the selected OOXML fallback variant.
14. If page setup, headers/footers, sections, tables, formulas, OLE objects, or columns are involved, read `references/equations-tables-sections.md` before those steps.
15. Before applying page setup, detect whether a mixed-column template or double-column fallback requires target section-structure repair. If the target has only one section and the template/fallback clearly has front/body sections with different column counts, insert a conservative continuous section break before the target body start. For weak/non-`.docx`/blank-carrier double-column fallback, front matter stays single-column and body starts double-column; never apply double columns to the whole single-section document when the body start is unclear.
16. Apply page setup and headers/footers to every section, including paragraph-level `pPr/sectPr`.
16a. Clean inherited target header/footer background watermarks before template header/footer import. Remove image-only target `header*.xml`/`footer*.xml` paragraphs whose drawings are behind text or large anchored background images. Do not remove header/footer paragraphs containing visible text, page fields, tabs/breaks, body images, or normal template header/footer content imported afterward.
17. Identify target paragraph roles without trusting target styles, and audit the `role_map` before style injection. Display equations/formulas must be mapped as the independent `equation` role before generic `body`. For template role-source extraction, run content-consistency checks before accepting any paragraph as the sample for `title`, `author`, `body`, or other core roles: publisher metadata, DOI/date/copyright/received/revised/accepted notes, footnotes, operation instructions, and placeholder/rule prose are not representative paper content even when they appear early, have large fonts, or use custom Word styles.
18. Install styles from the intermediate spec and bind target roles to those styles only after the role-map preflight. For `blank_carrier_template` and other weak external style sources, also write the body fallback baseline into target `docDefaults` and `Normal` before binding so an unbound or body-like paragraph cannot display with the carrier's Word default single spacing.
19. If numbering, bibliography, reference citations, heading auto-numbering, or superscripts are involved, read `references/references-numbering-superscript.md` before those steps.
20. If any role style contains `w:numPr/w:numId`, copy the corresponding template `numbering.xml` `num` and `abstractNum` definitions into the target, allocate new non-conflicting IDs, and rewrite role style `numId` values to the new target IDs. `reference_item` is excluded only when the template uses visible text reference prefixes; it must be included when the template uses Word automatic bibliography numbering.
21. During role-style installation, after `reference_numbering_map.json` is known, enforce reference-list indentation mode. In visible-text or non-automatic reference numbering, if `reference_item` has no explicit `w:ind`, create `<w:ind w:left="420" w:hanging="420"/>`; if it has `hanging` without a safe `left`, add/raise `left`. In Word automatic numbering mode, do not add style-level hanging indentation because numbering levels usually control it.
21a. For weak/non-DOCX text-rule sources with no reliable Word XML numbering evidence, use the standard reference-list numbering fallback `[1]`, `[2]`, ... only for paragraphs mapped as `reference_item`, unless explicit text rules specify another prefix style or disable numbering. Never add numbers to body citations, headings, formulas, captions, URLs, DOI-only continuation lines, or any paragraph outside `reference_item`; ask the user to confirm bibliography order in the final notes when numbers were added or renumbered.
22. For heading roles, if a target heading already begins with a manual number but the generated heading style uses Word automatic numbering, use a no-number mirror of that same generated heading style for only that paragraph. Preserve template automatic numbering for plain headings without manual prefixes.
23. Extract template equation tab-stop layout and equation-number tab layout into `equation_layout_map.json` only for internal audit or when requested.
24. Extract template table body formatting into `table_format_map.json` only for internal audit or when requested. This is separate from `table_caption`.
25. If the template has no usable table XML evidence, or only weak/placeholder table evidence, use the selected variant's bundled OOXML three-line table fallback for both Chinese and English templates. The fallback may only change borders and cell vertical alignment/margins from the sample XML: top rule, header bottom rule, bottom rule, no vertical/internal grid lines. Do not rely on table-level `tblBorders` alone; also write cell-level borders for first-row top, inferred final-header-row bottom, final-row bottom, and explicit `none` for left/right/internal borders. Multi-row headers must be inferred from merge topology, spanning group cells, short label/subheader rows, and the first data-like row; put the header-bottom rule below the final header row such as `准确度` over `Top1/Top5`, not blindly below row 1. When a composite header has more than one row, also write a thin horizontal separator between header levels. Preserve table width, row/column count, merge topology, cell text, formulas, drawings, and media, and report the fallback for final visual confirmation.
26. Extract template reference-list numbering evidence into `reference_numbering_map.json` only for internal audit or when requested.
27. Extract template run-level superscript markers and write `superscript_map.json` only for internal audit or when requested.
28. Clean direct paragraph/run formatting unless the user explicitly disables it.
29. Run format-conformance QA immediately after role binding/direct-format cleanup and before reference numbering, table body, equation tab, and superscript passes. Compare `role_map.json` to the final target paragraphs and `style_spec.json` to the installed role styles. If a paragraph is bound to the wrong role style, or direct paragraph/run formatting still overrides role font,字号,颜色,加粗、缩进、行距、对齐等确定性属性, repair it automatically and audit again. Do not merely report deterministic conformance errors. Only unresolved or evidence-uncertain items become user notes.
30. Apply reference-list numbering repair after role binding, conformance repair, and cleanup, only to target paragraphs already mapped as `reference_item`.
31. Apply table body formatting after conformance repair, never by rewriting cell text, formulas, drawings, or merge topology. If final section geometry has multi-column body sections, constrain oversized inline/floating drawings and wide tables in those sections to the active column text width unless the object is clearly a small icon/logo. Preserve aspect ratio, cell text, formulas, media, and table topology; report scaled objects as visual-confirmation risks.
32. Apply equation tab-stop layout after conformance repair, never by rewriting OMML formula content. If the template lacks numbered-equation tab-stop evidence, use the computed equation fallback for both Chinese and English templates: compute center and right tab stops from the equation paragraph's active section/column width, not the full page width. In two-column sections, the right tab must be the column right edge.
33. Apply run-level superscript markers after conformance repair, never as whole-paragraph styles.
34. For abstract/keyword paragraphs, keep the role style content non-bold and apply run-level bold only to the leading labels `摘要`, `关键词`, `Abstract`, and `Key words`/`Keywords`; the following abstract/keyword content must remain non-bold. In weak-source fallback, abstract and keyword content defaults to five-point size (`w:sz=21`).
34a. Abstract/keyword label recognition must include bracketed and colonless variants: `[Abstract]`, `【Abstract】`, `ABSTRACT`, `[摘要]`, `[Keywords]`, and `KEY WORDS`. These labels should map to abstract/keyword roles before heading/title/body heuristics, and the label run must be bold while following content is explicitly non-bold.
35. After role-map-dependent passes, normalize explicit Chinese classification metadata containing `中图分类号` and `文献标志码` to one line using a right-aligned tab stop 

…(truncated)