Establish replacement main and maintained content 1.x release lines

[zoeyrose]

Outcome

Operate atrinik/content@1.x as the maintained content release line for the classic GPL server/client/editor while content@main remains the forward development line for the MIT replacement stack and may migrate the authored corpus to JSONL or another approved schema.

The 1.x branch was created from released main commit 01b1fdb65c2243df4bafe9c8109fc93229df0121 (v1.8.1). Creating the branch does not relicense any content, script, tool, or asset.

Established baseline

• refs/heads/1.x was created from v1.8.1 / 01b1fdb65c2243df4bafe9c8109fc93229df0121.
• github-settings#26 merged as d14656fce8d39bffd8eeff12d18b099aad0feb46 and was applied.
• Live organization ruleset 20571870 protects exact repository content and ref refs/heads/1.x from deletion/non-fast-forward updates, requires linear pull requests, and strictly requires Conventional PR title.
• Content validation remains intentionally unenforced until this issue makes the workflow publish that check on 1.x; governance must then be tightened in a coordinated follow-up.

Fixed ownership and compatibility decisions

• main owns forward authoring, provenance work, new content-toolkit adoption, compiled artifacts, and eventual whole-corpus format migration for the Go/Rust replacement.
• 1.x owns only content and tooling that must remain consumable by classic/server, classic/client, classic/editor, and other explicitly retained classic consumers.
• Both branches remain in this repository so content identity, attribution, and history remain connected; do not create a duplicate content repository.
• The wrapper exposes the same repository twice through distinct component identities/checkouts: replacement content selects main; classic content selects 1.x.
• Per-file and mixed licenses remain authoritative on both branches. Neither branch name nor an MIT engine/toolkit changes corpus licensing.
• After source formats diverge, never merge main wholesale into 1.x. Backports and forward ports are explicit, reviewable pull requests that preserve attribution and validate the destination consumer set.

Scope

• Add branch-specific repository governance for 1.x: deletion/non-fast-forward protection, linear history, pull requests, and—once the workflow emits them—Content validation plus Conventional PR title.
• Extend content CI to validate pull requests and pushes targeting 1.x with the classic-compatible validation/build/release inputs present on that branch.
• Configure semantic-release as a real 1.x maintenance channel without competing with main; document the required ordering/version-range behavior before the first post-fork release.
• Produce branch-aware release metadata that names source branch and commit, content/artifact format, a compatible unified atrinik/classic release range, checksums, and exact licenses/attributions.
• Define backport labels/process, conflict handling, security/data-loss priority, and how a fix is independently proposed for main when still applicable.
• Add a machine-readable compatibility fixture proving the classic collector/server/editor modules can consume the 1.x release and the replacement toolkit does not accidentally publish it as replacement-ready content.
• Coordinate wrapper component registration and isolated checkout/build paths through Workspace: relocate classic checkouts without overwriting work atrinik#262, #263, and #266.

Safety and failure behavior

• Do not force-push, reset, delete, or recreate 1.x.
• Do not silently regenerate or normalize the corpus during a backport.
• A change that requires replacement-only JSONL/schema/tooling is rejected from 1.x unless a separate classic-compatible implementation is explicitly justified.
• A missing required check, ambiguous target branch, incompatible artifact, incomplete attribution, or semantic-release version conflict fails before publication.
• Builds for main and 1.x use separate worktrees, caches, outputs, and collected runtime directories.

Acceptance criteria

• GitHub shows refs/heads/1.x at the recorded v1.8.1 fork point and protected by desired-state governance.
• A test pull request targeting 1.x runs stable validation and PR-title checks; merge and direct-push behavior match policy.
• A semantic-release dry run demonstrates the 1.x maintenance range/channel and cannot consume or overwrite a main release.
• A classic content release manifest identifies content@1.x, exact commit, compatible classic releases, checksums, and every applicable license/notice.
• Wrapper fixtures resolve content@main and content@1.x to different checkout identities and never share generated output.
• Documentation tells maintainers exactly whether a change belongs on main, 1.x, or both via separate pull requests.
• No gameplay or authored-content design choice is changed by establishing the release line.

Dependencies and parallelization

Branch governance, CI/release configuration, compatibility metadata, and wrapper schema/tests can be developed in parallel. Required-CI enforcement must wait until the 1.x workflow actually publishes the stable checks, preventing a branch-protection deadlock.

Links: atrinik/atrinik#168, atrinik/atrinik#263, atrinik/atrinik#266.