[12-2] Write the paper/preprint and prepare the repository release

[duckyquang]

Goal 12, Task 2 — [12-2] · GEML Goals 6–12 (roadmap, README §5) · Size: M

Independence

Hard prerequisites (genuinely required): [12-0]. These cannot be stubbed: the paper is written from the verified final report; per the team plan, writing starts ~5–7 days before the deadline from [12-0]'s content.

What can start early, before the prerequisites merge: maintain the running outline and figure list as gate verdicts land, so the final writing sprint only assembles.

• Exclusive write set — no other issue edits your owned paths, so your PR cannot conflict with parallel work.
• Branch: issue/12-2-<short-slug>.

Objective

Write the MathNLP 2026 paper/preprint from the final report under the agreed claim discipline, and prepare the public repository release.

Exclusive file ownership

Owned paths — this branch may edit only these paths:

• docs/paper/OUTLINE.md
• docs/paper/FIGURES.md
• docs/RELEASE_CHECKLIST.md

Read-only dependencies:

• Final report [12-0]
• reproducibility package [12-1]

Tasks

• Maintain the outline and figure list continuously; start full drafting ~5–7 days before the deadline (2 writers, per the team plan).
• Enforce claim discipline: every paper claim maps to a report section and artifact; null results stated plainly.
• Prepare the release checklist: license, README final pass, artifact links, citation file, version tag.
• Route the draft through the two-review policy (technical + scientific-contract).
• Tag the release only after [12-1] verification passes.

Acceptance criteria

• Every paper claim is traceable to [12-0].
• The release checklist is complete and the repo tag matches the paper's reported commit.
• Claim discipline is verified in review, including the speculative-remarks boundary.

Validation

• Checklist review; no automated validation beyond CI green at the release tag.

Out of scope

• Do not add new experiments during the writing window.

PR checklist

• I edited only the owned paths listed above.
• I did not inspect or reuse the previous GEML implementation.
• Tests use temporary/tiny fixtures and do not require production outputs.
• Failures and unsupported cases are retained and reported, not silently dropped.
• I included exact reproduction/validation commands in the PR description.
• I documented any scientific metric or assumption change.

Clean-room rule: Implement only from the current repository specifications and authoritative public sources. Use the v0 prototype only to understand what was measured and why — never as a code template. If an interface is ambiguous, stop and ask rather than modifying another issue's contract.