Scientific Rewrite

Scientific Rewrite

This is the heavy Chinese rewrite route inside writing-style. Use it when an ordinary user provides existing Chinese or Chinese-dominant scientific/technical material and asks to reorganize, restructure, or rewrite it into clearer Chinese while preserving exact scientific details. The user does not need to name this skill or any internal route.

The routing signal is the combination of all three conditions:

• existing Chinese or Chinese-dominant scientific/technical source material;
• a request for reorganization, structural rewrite, or document-level rewrite, not only local polishing;
• explicit preservation pressure on facts, numbers, formulas, citations, comparisons, conditions, limitations, paths, configuration keys, commands, or other exact details.

Do not wait for the user to say scientific-rewrite, Meaning Map, Reader Plan, REALIZE_MEANING, or another internal term. Those are implementation details, not user-facing activation words.

The ordinary user should not need to name this skill. A natural request such as "把这份较长科研报告重新组织成自然中文，数字、公式、引用、比较条件和限制都不能丢" should be routed here by the installed writing-style plugin when the source is long enough to need document-level meaning planning.

Boundaries

• Host Codex owns semantic extraction, planning, realization, audit, repair, assembly, and final prose. Do not call paid OpenAI/Terra generation in these stages.
• rewrite_support.py is mechanical only. It validates schemas, source-anchor coverage, ordinary route selection, exact items, source/repair/assembly leakage, and receipts. It does not generate reader-facing prose or certify naturalness.
• chinese-prose owns REALIZE_MEANING: turning an already-fixed semantic packet into natural Chinese.
• writing-fidelity owns STRUCTURAL_REWRITE: preserving the content/evidence graph while allowing source headings, paragraph boundaries, and section order to change unless the user explicitly protects them.
• Existing scientific-prose remains the English scientific prose route.

Heavy Path

raw source
-> ordinary writing-style route selection
-> source anchors
-> Meaning Map
-> Reader Plan
-> REALIZE_MEANING
-> assembly
-> exact + semantic fidelity audit
-> structured targeted repair when needed
-> re-assembly when needed
-> re-verification
-> final candidate

REALIZE_MEANING uses soft isolation. The host model may have seen the raw source earlier in the same task, but the formal realization packet must not re-present raw source paragraphs, source excerpts, source quotations, source tails/previews, source-shaped templates, prior rejected candidates, manual reference output, Latin-span inventories, QA ledgers, or validator fields as drafting input.

Do not create nested codex exec, a second model runtime, or another isolation system only to claim that the writer forgot the source.

Route Selection

The installed writing-style entrypoint must select this heavy route from an ordinary user request. The prompt may ask to rewrite a longer Chinese scientific or technical document naturally while preserving numbers, formulas, citations, comparisons, conditions, and limitations. The prompt must not name scientific-rewrite, Meaning Map, Reader Plan, REALIZE_MEANING, internal stage names, or validator names.

Record route evidence in route_selection.json before validating the stage package:

• schema: SCIENTIFIC_REWRITE_ROUTE_SELECTION_V1;
• selector_owner: writing-style;
• selected_route: scientific-rewrite;
• forced_route: false;
• ordinary_user_prompt: true;
• prompt_sha256 and source_sha256;
• prompt_internal_terms: empty list.

A forced subskill invocation is diagnostic only. It cannot satisfy the ordinary production route gate.

Meaning Map

The Meaning Map is meaning-centric and source-auditable. It must include:

• stable source anchors with hashes;
• meanings with meaning_id, kind, normalized_meaning, source anchors, and exact items where needed;
• source_context_items for source packaging, workflow debris, navigation wrappers, alternate-language labels, or other source authority that is useful for judging relevance but should not become reader-facing content;
• relations when one meaning depends on, qualifies, compares with, or limits another;
• exact items whose literal identity matters;
• bidirectional coverage: every substantive source anchor has meaning ownership or explicit source-context exclusion, and every meaning has source authority.

Missing or malformed semantic extraction is a failure/repair condition. The helper must never fill normalized_meaning from source excerpts or continue with a source-copy fallback.

Reader Plan

The Reader Plan owns reader-question order, semantic dependencies, bundle ownership, and information shape. It must not contain raw source prose, source excerpts, target rewrite sentences, Latin-span QA classifications, seed templates, or validator language.

If the Meaning Map contains source-context exclusions, the Reader Plan must list their IDs in excluded_source_context_item_ids. This makes reader-facing omission explicit and auditable instead of silently dropping source spans.

Mechanical size limits may only request NEEDS_SEMANTIC_SPLIT; they must not become the production heavy planner. Fixed 4 paragraphs / ~2800 chars chunking is not a valid final heavy-route boundary.

The Reader Plan is also the reader-disposition contract. Every retained, relocated, structured, or omitted obligation needs a source role and a reader reason. Use the existing plan/bundle structure; do not create a parallel persistent ledger. Valid disposition families are:

• CORE_INLINE for central claims, definitions, mechanisms, and evidence;
• SUPPORT_INLINE for needed conditions, caveats, comparisons, and context;
• STRUCTURED for formulas, tables, citations, legitimate code, commands, APIs, config, or identifiers that must appear as structured objects;
• RELOCATE for needed reproducibility details that belong in a technical note or appendix rather than the main argument;
• SOURCE_FUTURE_WORK for source-author future work, limitations, or proposals whose subject, tense, completion state, and uncertainty must be preserved;
• DROP_WRAPPER for navigation, export UI, license debris, duplicated links, or source packaging that is not part of the reader-facing content;
• DROP_IRRELEVANT_TRACE for task, review, branch, commit, CI, cache, or workflow traces that only describe how a prior artifact was produced.

Citation identity is not the same as raw citation markup. If the source comes from a wiki, scraped web page, exported Markdown, or HTML document, templates such as {{sfnp|...}}, {{harvtxt|...}}, {{cite ...}}, <ref>...</ref>, <references/>, and similar source-site citation syntax must be classified as wrapper syntax unless the user explicitly asks for source markup preservation. Keep the cited authors, years, titles, or source note when they support a reader-facing claim, but realize them as normal prose, a bracketed citation, or a short references/source-note section. Do not emit the raw template or tag in a standalone candidate.

SOURCE_FUTURE_WORK must carry modality information: who owns the future work, whether it is done or proposed, its temporal status, and its epistemic status. Do not turn source-author plans or limitations into current Executor actions or completed findings.

Realization Packet

A REALIZE_MEANING packet may contain:

• audience and register;
• bundle purpose and reader question;
• relevant meaning and relation records;
• required exact item identities/formulas;
• neighboring bundle purposes/dependencies;
• information shape;
• optional structured repair instruction.

It must not contain raw source paragraphs, source quotes, source excerpts, source tails/previews, old candidates, manual reference text, Latin-span inventories, seed rewrite templates, or self-audit ledgers as drafting input.

Formula rendering is a production obligation, not a cosmetic choice. When a source formula is reader-facing, realize it as renderable Markdown/LaTeX math ($...$ or $$...$$) with nearby Chinese explanation. Do not place formulas inside fenced code blocks, inline code spans, text fences, quote blocks, screenshots, or token inventories merely to preserve characters. A formula-like code block or inline-code span is a candidate-representation failure even when the literal symbols are present. Use normal LaTeX math notation for operators and spacing, such as \log, \sin, \cos, \exp, \min, \max, \arg\min, \arg\max, \Pr, and \mathbb{E}. Big-O and complexity expressions such as O(n log n), O(N log N), and (N/2) log_2 N should become $O(n \log n)$, $O(N \log N)$, and $(N/2) \log_2 N$, not inline code and not $O(n log n)$, because the latter renders log as ordinary adjacent variables.

The packet must explicitly preserve modality. It must tell the writer to keep completion status, subject/voice, temporal status, and epistemic status from the Meaning Map and Reader Plan. This is especially important for future work, limitations, negative results, author proposals, conditional statements, and unverified observations.

Assembly

Assembly may consume Reader Plan, realized bundles, meaning ownership, bundle order/dependencies, required exact objects, and terminology established by the realized bundles. It may add headings/transitions that add no scientific claim, remove duplicate definitions while preserving ownership, and place formulas, tables, or lists near their explanation.

Assembly must not receive the raw source as drafting material and must not become a second whole-document source-conditioned writer.

Assembly owns whole-document finish. Before accepting a final candidate, it must state the document purpose, reader entry, section-order rationale, transition plan, voice constraints, and technical-detail placement. The candidate should read as a standalone scientific or technical document, not a memo about a source file, task branch, review process, or next execution step.

Repair

The semantic auditor may read raw source. A repair packet sent back to REALIZE_MEANING may only contain structured corrections:

• bundle id;
• affected meaning IDs;
• finding type;
• required semantic correction;
• required exact-item IDs;
• allowed semantic operations.

It must not contain source prose, source quotations, source sentences, or a target rewrite sentence. If the Meaning Map is wrong, repair the Meaning Map first and update the Reader Plan before re-realization.

The semantic audit must check disposition as well as proposition fidelity. It must verify that each source obligation is preserved, summarized, relocated, or omitted according to the Reader Plan, and that no critical disposition finding remains unresolved. This prevents two opposite failures: preserving every internal trace for "fidelity", or deleting legitimate code, formulas, reproducibility details, citations, limitations, or future work for "cleanliness".

Exact Items

An ordinary Latin technical word is not exact-protected merely because it is Latin script. Exact preservation is for formulas, citations, machine-facing tokens, paths, commands, config keys, code identifiers, formal algorithm/model names, datasets, metrics, packages, APIs, and user-explicit protected spans. Ordinary reasoning, comparison, qualification, and transition language remains eligible for natural Chinese realization.

For citations, exact preservation protects citation identity and attribution, not source-platform syntax. Wiki templates, HTML reference tags, scraped footnote wrappers, and citation parser artifacts are not reader-facing exact items. Convert them to readable citation wording or a compact reference/source note, or omit them when the Reader Plan classifies them only as wrapper metadata.

Reader-Facing Relevance Filter

Do not treat repository workflow metadata as reader-facing scientific meaning merely because it is exact. The heavy route must distinguish scientific reproduction details from internal execution traces.

Keep exact script, configuration, command, data, model, metric, citation, or formula identities when they support the scientific/technical argument or reproducibility contract. For example, a source statement that an experiment uses scripts/run_fedfisher.sh and configs/mm_fedfisher.yaml may remain in a short reproducibility paragraph.

Formula identity means preserving the mathematical relationship in reader-facing math, not preserving the source's plain-text container. If the source expresses DFT, loss functions, matrix equations, Big-O/complexity statements, or other formula-like content in plain text, inline code, or a wiki-style block, convert the relationship to renderable math and explain the symbols. Use code fences and inline code only for real code, commands, APIs, configuration, or machine-facing tokens, not mathematical notation.

Reader-facing exact verification checks exact items required by meanings or Reader Plan bundles. Exact items that appear only inside excluded source_context_items are not required in the final candidate, but an inline-critical exact item must not be hidden this way. If a method name, model, dataset, API, citation, metric, path, command, or formula is needed to understand or reproduce the technical point, keep it reader-facing.

Do not put these in the main reader-facing candidate unless the user explicitly asks for an audit log or repository handoff:

• Reviewed Handoff state, Gate numbers, Planner/Reviewer/Executor status, CI status, test command summaries, or Text Review workflow state;
• Git commit hashes, branch names, GitHub Actions run ids, worktree state, or release checklist status;
• task-local paths such as results/<task_key>/*, exports/private/*, automation/reviewed_handoff/*, .local-runtime/*, plugin cache paths, or CURRENT.json / RESULT.md / FINAL_REPORT.md;
• statements such as "this round is ready to close", "waiting for external planner review", or "the result has passed independent planner review" when they are process state rather than scientific content.
• webpage/export wrappers such as language-link counts, archive ids, alternate-language labels, navigation labels, or scraped UI noise when they do not help a standalone reader understand the technical content.
• raw citation wrappers from source platforms, including wiki templates and HTML reference tags, unless the user explicitly requested markup/source comparison. Preserve the citation's useful identity, not the platform syntax.

If the source mixes a scientific report with workflow/audit metadata, use the metadata only to avoid false claims and to understand artifact authority. The final candidate should present the scientific content first and move necessary technical reproduction details to a short appendix. Irrelevant workflow traces should be omitted, not "preserved" as prose.

Source-Process Framing

A standalone reader-facing scientific or technical rewrite must not explain the text as a rewrite of a source document. The final candidate should state the technical object, notation, result, limitation, attribution, or comparison directly.

Do not write source-process frames such as:

• "原文指出";
• "原文同时提到";
• "原文在……中";
• "根据给定材料";
• "源文";
• "这里保留原文".

The semantic audit must classify these as reader-facing frame failures when the task is a normal standalone rewrite. Repair the affected block by stating the technical content itself: name the method, notation, experiment, theorem, claim, caveat, or cited author directly. Do not simply replace "原文" with a synonym such as "材料" or "上文".

This rule is contextual, not a phrase blacklist. It does not remove legitimate scientific attribution. For example, "Smith et al. [12] reported ..." or "文献 [12] 报道 ..." should remain when the source attributes a claim to those authors or that paper. It also does not apply when the user explicitly asks for source comparison, editing commentary, peer review, provenance, or audit output.

Completion Standard

This route can claim process completion only when the stage package validates:

• ordinary writing-style route selection chose scientific-rewrite;
• no raw-source drafting leakage into realization, repair, or assembly;
• complete source-anchor/meaning ownership;
• explicit source-context exclusion for non-reader packaging metadata;
• valid Reader Plan bundle ownership;
• reader-facing exact items preserved;
• formulas and complexity expressions are renderable math, not fenced text, code blocks, or inline code spans;
• citations are reader-facing citation text, bibliography/source notes, or intentional omissions according to the Reader Plan; raw wiki/HTML citation markup such as {{...}}, <ref>...</ref>, and <references/> is absent from standalone candidates unless explicitly requested by the user;
• reader-facing candidate has no internal workflow / CI / commit / task-path leakage;
• standalone reader-facing candidate has no source-process framing such as referring to "原文", "源文", or "给定材料" instead of stating technical content directly;
• semantic audit has no unresolved critical findings;
• no paid generation dependency;
• no private plaintext committed;
• final candidate hash binds the receipt.

Validate with either current or compatibility command spelling:

python3 skills/writing/core/scientific-rewrite/scripts/rewrite_support.py validate-host-stage \
  --source SOURCE.md \
  --stage-dir stage_packets \
  --prompt USER_PROMPT.md \
  --receipt stage_packets/stage_receipt.json

This is not product-quality PASS. Human artifact acceptance and the task's Reviewed Handoff gates still own reader-facing quality.