fix(release): restore 1.x publication after the v1.9.0 collision

[zoeyrose]

Problem

The maintained Classic content line can no longer publish releases. The latest successful 1.x release is v1.8.5, but the branch now contains validated Classic changes—including authored colored-light data—that are not present in any published Classic runtime archive.

The latest Semantic Release run found 13 commits after v1.8.5 and selected 1.9.0 because the range includes feat(...) commits. Publication then failed with EINVALIDNEXTVERSION: main already owns immutable tag v1.9.0, so 1.x may publish only >=1.8.5 <1.9.0.

Evidence:

• failed run: https://github.com/atrinik/content/actions/runs/31538315179
• latest published Classic content: https://github.com/atrinik/content/releases/tag/v1.8.5
• first colored-light authoring commit: 0eea49ef65f21b7b02defda2fdaaf7f8292c17fd
• current release contract: contracts/release-lines/classic-1x.json
• current branch/release policy: .releaserc.cjs, AGENTS.md, and docs/RELEASE_LINES.md

The unreleased range currently contains these feature-classified squash commits reported by Semantic Release:

• 0eea49ef65f21b7b02defda2fdaaf7f8292c17fd — feat(lighting): author colored light sources (#64)
• ead72ef831444c874f65da841498924bab625e99 — feat(maps): persist the Incuna Sam objective (#63)
• 9d5aa3c88becabd33247418af76b2866376ce92b — feat(lighting): audit effective light-source colors (#67)
• ca2ed0f966cc66de40f6e393cc8e93a7c97867f0 — feat(quests): teach the Incuna apartment flow on 1.x (#112)
• d2387818a014536da84833d6f8179e9112b9f6c8 — feat(archetypes): make fire fixtures emit light (#115)
• 7575b438ae985bfa4a2347776a27c37368f5ee0a — feat(maps): transfer crystal light ownership (#116)

Required outcome

Restore automatic 1.x publication without moving, deleting, or reusing an existing tag, and publish a checksum-bound Classic runtime archive containing the current validated 1.x content.

Implementation requirements

• Add a narrowly bounded recovery rule for the already-merged feature commits above so this historical unreleased range produces a patch within >=1.8.5 <1.9.0.
  • Match the exact committed subjects/scopes or another equivalently fail-closed identity.
  • Do not add a blanket rule that silently reclassifies every future feat on every release line.
• Define and enforce the future 1.x commit policy so another minor release cannot accumulate behind the v1.9.0 boundary.
  • Reject feature/breaking pull-request titles on 1.x, or replace the version namespace through an explicit reviewed release-contract migration.
  • Keep main behavior unchanged.
• Keep Semantic Release as the sole tag/release publisher; do not create a tag or release manually.
• Preserve the maintenance channel and the immutable history through v1.8.5.
• Update .releaserc.cjs, workflow/contract tests, AGENTS.md, and docs/RELEASE_LINES.md together.
• Ensure release failure reporting preserves the original Semantic Release error and does not obscure it with a secondary issue-creation failure.

Acceptance criteria

• A Semantic Release dry run on the exact reviewed 1.x head selects the next available 1.8.x patch, not 1.9.0.
• The normal post-merge workflow publishes that version on the 1.x channel.
• The runtime asset contains manifest.json schema version 2 with:
  • source.repository == "atrinik/content";
  • source.branch == "1.x";
  • source.commit equal to the release tag commit;
  • release_line == "1.x";
  • replacement_ready == false;
  • replacement_toolkit_package == false;
  • compatible_classic_releases still covering supported Classic 5.x releases.
• SHA256SUMS verifies both published archives.
• The runtime archive contains explicit light_color fields and the files introduced by the reviewed lighting work.
• Existing tags and releases are unchanged.
• A regression test proves that an ordinary future feat(...) on 1.x cannot recreate an out-of-range release silently.

Validation

• python3 tools/validate.py
• the repository's focused release-guidance and packaging tests
• Semantic Release dry run for 1.x
• build and inspect both release archives and manifest.json
• verify SHA256SUMS
• git diff --check

Rollback and recovery

If the production release fails before creating a tag, fix the reviewed automation and rerun it. If it creates immutable release state, follow the repository's documented recovery path; never delete or move the tag to retry.

[zoeyrose]

Stage 1 is ready for human review and merge in PR #164.

• base: 1.x@4711f1e754506d4786e12116d61bec7ea9f0da56
• reviewed head: 5d9589382b7334f2de4465c6146a305bfdbdb43c
• exact-head dry run: all 18 post-v1.8.5 commits classified patch; 1.8.6 selected with publication skipped
• current-head checks: Content validation, Conventional PR title, and both syntax-prototype jobs passed
• review: zero known actionable findings; mergeable and clean

This sole 1.x PR intentionally does not close the issue. After merge, the normal workflow must publish the release; the program will inspect both archives, SHA256SUMS, manifest identity/compatibility, and colored-light content before advancing.

[zoeyrose]

Post-merge verification is complete for v1.8.6.

• merge/tag commit: 9279e0460179df8322d30e05f2c748dd2e3d2272
• release workflow: run 31546289628, passed
• source archive SHA-256: 9fdd411f7432088dd5fec776dc511ad3fa2e4589401e711bcafd592b92f4b96c
• runtime archive SHA-256: 3d525017f96de86e659feaa06923c633bb858d61e811560fb3892af01b47cd3f
• SHA256SUMS verifies both archives and matches GitHub's asset digests
• schema-v2 manifest identifies atrinik/content@1.x, version 1.8.6, the exact commit above, Classic >=5.10.1 <6.0.0, and both replacement flags as false
• all 4,180 manifest file digests/sizes and 157 license records verify; explicit light_color data is present
• v1.8.5 tag and asset digests remain unchanged

The program can now advance to atrinik/github-settings#63. This issue remains open for the required human closure step.

[zoeyrose]

The first real updater cycle correctly failed closed at the consumer gate.

Manual updater run https://github.com/atrinik/classic/actions/runs/31552330984 succeeded and created exactly one App-owned, lock-only PR: atrinik/classic#180. Its normal Server validation exposed a real defect in content v1.8.8 (also present in newly published v1.8.9): QuestManager.use_qp() uses invalid isinstance(delay, (int, None)) when a repeat quest has no configured delay.

Paired content fixes are now ready:

1. Merge main PR fix(quests): accept unset repeat delay #169 at exact head 60eb99a3a005d7df514c7bde2102a5edf667f892.
2. Merge 1.x PR fix(quests): accept unset repeat delay #170 at exact head d565fad745915d47d2691347e288eeaaa8f44161.

Both are mergeable clean, one-line diffs, all required checks green, and have no actionable conversations. After both merge, normal Semantic Release must publish the corrected 1.8.x patch; only then will the updater refresh PR #180 and rerun Classic validation. Do not merge #180 in its current state.

[zoeyrose]

Stage 5 reached a second fail-closed owner correction.

The v1.8.10 runtime is correctly published and verified, and updater run https://github.com/atrinik/classic/actions/runs/31553485823 refreshed the same App PR atrinik/classic#180 in place to exact head a3fc6e1561df1ca75d0fcc0a97afb0a0e39feb29.

The original TypeError is fixed. Server validation now reaches the regression's final assertion and shows that the fixture consumes its only available quest point while production intentionally retains terminal repeat state until another point is available. Production behavior remains unchanged; paired fixture fixes establish/assert the prerequisite and restore all mutated state:

1. main: fix(quests): isolate repeat reset prerequisites #172 at 7b5047b4513886a6c0a6eb518304d23fe14511d9
2. 1.x: fix(quests): isolate repeat reset prerequisites #173 at 3d60a7a573e5d4c7ca8880adf5144099a0276157

Both PRs are mergeable clean, all local and remote checks pass, and they have no actionable conversations. Merge #172 first, then #173. Do not merge Classic #180 until the next 1.8.x runtime publishes, the App refreshes it, and full Classic validation passes.

[zoeyrose]

Classic PR #180 consumed verified v1.8.12 and exposed the remaining fixture/API mismatch: the test attempted activator.level = 10, while Classic correctly exposes player level as read-only.

The revised paired fixes preserve production and API behavior. They consume the naturally available point, advance the writable quest-container restoration clock by 20 hours, assert full point restoration, and then verify repeat reset:

1. main: fix(quests): model repeat point restoration #174 at eb1e62354cbfe40bc6ec551305af75db8f9b5b45
2. 1.x: fix(quests): model repeat point restoration #175 at 5997021dfe6ad9a974d096c7b0b8d575268f5551

Both are mergeable clean, all local and remote checks pass, and they have no actionable conversations. Merge #174 first, then #175. Keep Classic #180 unmerged until the next 1.8.x release is verified and the App refresh passes the complete Classic suite.

[zoeyrose]

Release publication was restored and remained fail-closed within the 1.8.x range. The final maintenance release is v1.8.18, whose tag resolves exactly to 0032e319dde316c2076832066fb5381177b34f42; its source/runtime archives and SHA256SUMS were published by normal Semantic Release. Closing as completed. The single-source cutover is tracked separately by #166 / atrinik/atrinik#357.