Inventory classic editor and content-authoring behavior for replacement parity

[zoeyrose]

Outcome

Create the authoritative, reviewable inventory of every supported classic editor and content-authoring behavior that the MIT Rust editor/toolkit/renderer/wrapper stack must preserve, deliberately replace with an equivalent workflow, or retire only with explicit product approval.

This closes the missing editor-side counterpart to server#4, client#5, and content#41. It is a behavior/specification inventory, not permission to copy GPL implementation.

Scope

Audit the last supported classic releases, classic/editor, Gridarta/map-maker integration, retained content-repository tools, wrapper launch paths, and user documentation. Cover at least:

• installation, project discovery, configuration, opening/creating/saving maps, recent files, multi-map/tiled navigation, and recovery;
• map headers, regions, tiled neighbors, exits/backlinks, coordinates, layers, sub-layers, linked physical depths, and map metadata;
• archetype/object placement, multipart objects, inventories, containers, property editing, unknown/custom fields, messages, ordering, copy/paste, rotation/direction, search, palettes, favorites, and bulk operations;
• artifacts, animations, treasures, factions, interfaces/dialogue, quests, NPCs, shops/services, attribution, and every other supported non-map authored-content workflow;
• validation, map checking, collection/build/package steps, semantic diff, generated-file boundaries, preview, client-exact rendering, and isolated playtest;
• undo/redo, dirty-state behavior, atomic writes, external edits, malformed files, failure messages, keyboard workflows, accessibility, and platform-specific behavior;
• command-line or automation entry points used by maintainers even when the classic GUI did not expose them.

For every capability row, record:

• a stable capability ID and domain;
• classic release/entry point and independently observed user-visible behavior;
• representative separately licensed input fixture and expected outputs, diagnostics, mutations, and failure behavior;
• affected source/content formats and whether byte preservation, semantic preservation, or both are required;
• replacement owner repository, issue, milestone, API/command/UI surface, and automated or manual acceptance fixture;
• status: required, implemented, verified, approved-difference, or approved-retirement;
• provenance/license evidence for any migrated fixture, test, asset, documentation, or implementation fragment.

The manifest format must be machine-readable and mergeable with the program equivalence contract in atrinik/atrinik; rendered human documentation may be generated from it.

Equivalence rules

• Preserve authored data, gameplay/content design, safe-authoring guarantees, and reachable user outcomes; source layout, Java/Python internals, and exact UI chrome are not parity requirements.
• Unknown fields, comments, multiline text, nesting, ordering, attribution, and untouched bytes remain explicit lossless-editing requirements where the classic format permits them.
• A technical modernization may be recorded as an approved difference only when it does not silently remove a design choice or supported workflow.
• A required row cannot be closed by a prose assertion alone: it needs a deterministic fixture, an automation check, or a named manual acceptance procedure with captured evidence.
• Verified work from an approved MIT provenance grantor may be reused only under the merged complete-history grant policy; all other legacy implementation and tests remain behavior/specification evidence only.

Acceptance criteria

• Every supported classic authoring entry point, format, workflow, diagnostic class, and failure/recovery path is represented or linked to an explicit evidence-backed retirement decision.
• Every required row has exactly one implementation owner and a destination issue/milestone; no row is duplicated across editor, toolkit, renderer, or wrapper ownership.
• Representative fixtures cover ordinary and adversarial files, maps with linked/tiled structure, every authored-content class, and the complete edit/validate/preview/playtest loop.
• The inventory identifies all workflows needed to use and maintain the existing content pack, not only the M3 demonstration slice.
• editor#13 and atrinik#259 can be closed by burning this inventory down to zero unowned, unverified, or ambiguous required rows.
• A clean-room/licensing review confirms that the inventory and its fixtures do not import unapproved GPL implementation or mixed-license material into MIT repositories.

Dependencies and parallelization

This starts in M1 and can be split immediately by map editing, structured content, validation/build, preview/playtest, automation, and platform/recovery domains. It informs editor#3–#10 but does not block repository bootstrap or architecture work. It gates the editor replacement epic and the program-wide M5 equivalence gate.