Inventory classic behavior and runtime Python migration requirements

[zoeyrose]

Outcome

Create an independently written, reviewable migration manifest for every behavior needed from the classic server and content runtime. This is a behavior inventory, not permission to translate GPL implementation code.

Known estate to reconcile

The initial audit found:

• 130 runtime/map Python and test/mock files totaling about 15,435 lines.
• 117 production files totaling about 9,582 lines.
• 83 authored interface XML files.
• 16 authored quest XML files.
• Separate offline Python tooling under content/tools, which is not a server runtime dependency.

Recount these values from a pinned content revision and explain any difference.

Manifest fields

For every runtime script, interface, quest, command, and material observable server behavior, record:

• Stable manifest ID and source path/revision.
• Provenance/license status, exact authorship evidence, and whether the author is covered for the material by the merged approved MIT provenance-grantor registry in docs: register MIT provenance grantors atrinik#275.
• Player/operator-visible behavior, inputs, state, side effects, failure behavior, and persistence requirements.
• Replacement owner: native Go domain system, compiled authored data, typed CEL environment, explicit reviewed Go handler, optional Starlark candidate, offline toolkit, or deliberate retirement.
• Owning issue, protocol/content dependencies, acceptance fixture, and migration status.
• Any ambiguity requiring a product decision; do not silently infer one from legacy code.

Classification targets

• Quests and quest hooks → native Go quest engine plus compiled definitions.
• Interfaces/dialogue → native Go dialogue engine plus structured client model.
• Merchants, banking, auction, post, guilds, houses, apartments, guards, and jail → native Go services.
• Commands and global events → typed Go registries.
• Generic triggers and map-local behaviors → bounded action definitions or explicit Go handlers.
• Pure conditions/formulas → versioned, typed, bounded CEL.
• Starlark → only residual orchestration that cannot fit the above, after a separate go/no-go review.
• Python tests/mocks → independent Go scenario/service tests.

Acceptance criteria

• Every row has one owner and one independently testable observable contract.
• No row says only “port” or points at GPL source as its implementation specification.
• Runtime Python and offline tooling are clearly separated.
• The manifest supports domain-by-domain burn-down and reports zero unowned items.
• The new server has no CPython compatibility-host requirement.
• Verified exclusively owned content/tools files may be explicitly dual-licensed and reused by content-toolkit; this does not imply a grant for map/runtime scripts.

Parallel work

Inventory can be split by quest/interface, economy/community, commands/events, items/monsters, and map-local behavior. Reviewers should compare public behavior and authored data, not share implementation drafts derived from GPL source.

[github-actions]

🎉 This issue has been resolved in version 1.0.0 🎉

The release is available on:

• v1.0.0
• GitHub release

Your semantic-release bot 📦🚀