/paperfit

name: paperfit
description: Diagnose and repair LaTeX paper layout through PaperFit's structured visual closed loop over rendered pages, source-grounded repairs, and visual verification. Use for overflowing figures or tables, float placement, readability, and submission page budgets.

PaperFit

Execute PaperFit's structured vision-in-the-loop workflow in the current multimodal Codex, Claude Code, or Cursor session. PaperFit organizes visual diagnosis, source-grounded constrained repair, and checklist-based verification; the host model executes this workflow using PaperFit's domain knowledge and tools. Actual rendered-page feedback is required for layout repair and acceptance. An auxiliary vision API or separate agent may supplement this feedback; their absence does not make visual inspection optional.

Required visual closed loop

1. **Sense:** Compile and render the current manuscript, then actually inspect every physical page to establish the whole-document baseline. Diagnose visible defects using the PaperFit taxonomy and locate their source objects. Verify source/log measurements and auxiliary diagnoses against the pages. If the input cannot render, first restore compilation without claiming a visual repair; enter this visual loop as soon as current pages are available. 2. **Act:** Form a coherent repair candidate grounded in the diagnosis. A candidate is a reviewable source state after one related edit or a batch of related edits, not necessarily a fully repaired manuscript. Preserve a source/assets/PDF checkpoint, apply those changes under the content and template constraints, and state which defects the candidate addresses. Complete this planned batch before its visual verification; intermediate trial builds may help isolate risky edits. 3. **Verify:** Recompile and rerender each changed candidate, then actually inspect every physical page of its current PDF before retaining it or choosing the next repair. Check document-wide flow and visible content on every page at a readable scale; inspect target objects, shifted floats and suspected regressions in detail at useful zoom. Full-page coverage does not require identical inspection depth everywhere. Compare with the checkpoint, distinguishing resolved defects, unchanged pre-existing defects, new or worsened defects, and uncertain findings. Use the visual result to retain progress, revise or roll back; a clean build, page-count match or empty detector report cannot substitute for this step. Missing or unreadable pages leave verification incomplete; inspecting only changed pages does not satisfy this loop. 4. **Record and continue:** Retain a concise per-candidate record under `.paperfit/reports/` of the candidate/checkpoint identity, complete page set and page images actually inspected, diagnosed defects, source changes, visual observations, preservation/page checks, decision and remaining repair queue. Use `keep_and_continue` for verified intermediate progress and reserve `done` for final completion; these describe host decisions, not additional CLI statuses. Do not fabricate page views. Iterate while defects or requested constraints remain unmet within the actual task budget; report incomplete verification honestly.

Group related intermediate edits into one candidate; this loop does not require a full API call after every keystroke or waiting until every manuscript defect has been repaired. Whole-document inspection checks the consequences of the current candidate; it is not a zero-defect requirement for every round. A post-hoc evaluator score alone is not evidence that vision participated in repair. If no available model or image tool can inspect the current pages, report the visual-verification gap and do not claim a completed PaperFit visual repair.

Host authority and useful checks

The user's request defines the host's editing authority. For an authorized repair, use normal host tools on any relevant source, included file, local style/class, or project configuration within that scope. The host may reorganize related files, combine changes, or use a repair not listed in PaperFit. Tool support and taxonomy categories are not a permission ceiling. Do not ask the user to reauthorize routine related edits, and do not require a separate acknowledgement for every finding.

Treat rules, repair plans and auxiliary visual findings as evidence and advice. Resolve uncertainty by inspecting the source and pages; correct or reject a mistaken diagnosis. Record the reason for consequential decisions, not a ritual response to every suggestion. `human_review`, `approval_required` and unsupported-operation messages describe the optional batch route: the current host should investigate and continue an independently anchored native repair. They do not inherently mean waiting for another human or abandoning the task. Request clarification only when necessary user intent or authority is genuinely missing.

Group related edits into a coherent candidate, then compile and inspect its effects. Do not run every tool or regenerate every review after each intermediate keystroke. Ordinary native edits do not need typed-batch approval. Formal source/layout review records are used when seeking acceptance through a supported guarded route; their actual binding requirements still apply. Preserve scientific content, comply with the user's template requirements, and keep source/build/page evidence truthful. A final candidate needs a fresh successful build and inspection of every physical page; uncertainty or an unmet objective cannot be reported as `DONE`.

Establish the input and objective

Find the actual root `.tex` by its `\documentclass` and includes; do not assume `main.tex` or a bundled sample. Preserve author edits and identify the native template and compiler. A page objective applies only when requested: distinguish an upper bound from exact equality and body, reference and appendix scope. Readability, complete visible content, templ