X00-02 — Re-file parked legacy expansion candidates with value cases #141

Outcome

Each parked legacy candidate becomes a reset-repository record with a value case and a disposition.

Parent and boundary

Parent: #110. This is an expansion candidate. Produce a value case, owning module, contract sketch, and threat notes, then record go, no-go, or defer. No implementation lands from this issue. A new public PDF, schema, worker, or workflow contract needs an architect checkpoint with concrete fixtures and migration behavior.

Grounding

• Roadmap §5 keeps legacy #599 (1.0 scope routing), legacy #600-#610 (ink, imposition, marks, broad direct editing, collaboration), legacy #58, legacy #654, and benchmark-gated legacy #54-#57 as conditional. These are legacy numbers and are no longer reachable here.
• Preflight backlog P1 rows imposition-and-reader-spreads (legacy #603) and pdfvt-variable-data (legacy #605) have no reset issue.
• Completed drags are discarded: EditorHost::onDragCompleted drops the DragSession #104 (committing a completed drag) implies direct object editing, which the roadmap classes as an expansion candidate.

Decision inputs

• For each candidate: a one-page value case, a disposition, and, if kept, a reset issue with a verified number for overlay references.
• Backlog rows for imposition and PDF/VT point at their reset records.
• Failure case: a legacy number is never cited without the repository name.

Required proof

Decision record with the value case (user, frequency, current alternative, evidence), owning module, contract sketch, fixtures or corpus plan, independent oracle where a claim is made, and risks.

Handoff

State go, no-go, or defer. On go, file bounded implementation sub-issues under the owning module parent and link them here.

Sources

Approved master roadmap §5 · Gap review of the issue suite against the approved roadmap, 2026-09-27.