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)