feat(archetypes): make magic-wall runes emit restrained red light

[zoeyrose]

Architecture amendment — one authored content source (2026-08-13)

Initiative atrinik/atrinik#357 supersedes every future live-branch instruction below. atrinik/content@main is the sole mutable authored source for replacement and Classic targets. Future authored changes land only on main; supported Classic artifacts are deterministically derived from the same immutable main revision. Do not create, restore, author, backport, validate, or publish through a live 1.x branch.

Exact historical 1.x commits, tags, releases, assets, preserved local snapshots, provenance, parity records, and comparisons remain valid immutable evidence. This amendment changes no other feature, balance, lore, compatibility, licensing, validation, or ownership acceptance criterion.

Important

Evidence policy update (2026-08-11): #66 is complete through #124; any wording
below treating it as a future prerequisite is superseded. #126/#127 retire the
committed renderer-review capture surface. The removed files were generated
review artifacts, not authored gameplay art. Any requirement below to commit
rendered screenshots, contact sheets, manifests, proof maps, or capture tooling
is superseded. Keep authored semantic review in
maps/light-source-review.json (rationales, current digests, complete coverage,
and zero unreviewed emitters). Optional smooth/discrete diagnostics belong only
under ignored build/ or deployment output; summarize conclusions in the PR,
but never commit or gate merge on those files.

Follow-up to #65 and its implementation in #67, with the compatible main integration tracked by #66.

Outcome

Make the animated runes on magic_wall emit a restrained red light without representing the wall's active damage state as light.

The glow is an art-presence cue for the visible runes. Switches and lifecycle state must continue to control collision and firewall behavior independently.

Evidence

The exact #67 tree has 57 magic_wall placements across 10 maps, none with an effective radius or color:

Area	Placements	Initially active	Initially disabled
Plane of Creation	5	5	0
Temple of Loki	2	0	2
Brynknot Abyss	9	9	0
Underground City	37	12	25
Zechna Temple	4	0	4

Thirty-two placements are switch-connected, 31 begin with last_eat 0, and 37 are renamed for local security or priest-wall roles. Eleven share their tile with a neutral invisible source; 46 have no current source. The largest stress case is a 25-wall connected cluster in underground_city_2_3_-2.

The sprite has animated red/yellow runes. A radius-1 ff3030 source is the bounded starting point: large enough to make the rune surface read, but intentionally smaller than a room light or active firewall effect.

Scope

• Add ff3030 and the smallest rendered-effective radius, starting with radius 1, to the visible magic_wall archetype.
• Treat light as a persistent rune-presence cue; do not couple it to last_eat, switch state, damage ticks, or the type-62 firewall lifecycle unless a separate gameplay decision explicitly changes that contract.
• Review all ten maps, with special attention to the 25-wall Underground City cluster, narrow corridors, corners, and switch transitions.
• Reconcile the 11 same-tile neutral emitters deliberately and avoid accidental double sources.
• Coordinate the Underground City review with feat(lighting): make colored portal art emit matching light #86 because the same area also contains portal lifecycle work.
• Preserve names, switches, connections, collision, damage, timing, animation, placement, and every gameplay field.

Acceptance criteria

• All 57 visible walls appear as reviewed ff3030 emitters in the refreshed inventory.
• Radius remains local to the rune surface and does not turn dense wall runs into a uniform red wash or leak materially through adjacent geometry.
• Initially active, initially disabled, and switch-transition cases retain identical collision, damage, timing, and control behavior.
• The 11 neutral co-locations are migrated, retained, or excepted explicitly, with no accidental double lighting.
• Representative isolated walls and the 25-wall stress cluster are checked in smooth and discrete Classic lighting.
• The chore(maps): audit authored light-source colors #65 inventory, review records, semantic digests, evidence manifest, and affected rendered evidence are refreshed.
• python3 tools/world_content_audit.py lights --check, python3 tools/validate.py, and git diff --check pass.

Release lines

Land only after #65/#67 are integrated on 1.x and #66 supplies the matching field/audit contract on main. The affected definitions and maps are compatible across the two release lines; preserve line-specific metadata rather than copying files wholesale. Deliver separate linked pull requests, with Classic 1.x owning runtime evidence and main independently validating the authored mirror.

[zoeyrose]

Claimed for delivery. Preflight confirms this remains gated by the issue’s explicit prerequisites: #67 is open and unmerged on 1.x (latest head 958b557650252518b9ea2850200920d07c879bd2), and #66 has no implementation PR; current main does not yet expose world_content_audit.py lights --check. No #93 worktree or PR has been created, avoiding a duplicate or incorrectly based implementation. I will resume against fresh target-branch SHAs after both prerequisite integrations land.

[zoeyrose]

Status update (2026-08-11)

• feat(lighting): merge colored light content into main #66 is complete via merged PR feat(lighting): port reviewed light-source colors #124, so the compatible main companion for this issue is no longer prerequisite-blocked.
• chore(lighting): remove committed light-source evidence PNGs #126 is complete via merged PR chore(lighting): remove committed render evidence #127 and supersedes any requirement in this issue body or checklist to capture, pack, hash, or commit PNGs, contact sheets, capture manifests, or other rendered evidence.
• The durable review requirement is semantic: keep maps/light-source-review.json current with decision rationales, current source/map semantic digests, complete effective-emitter coverage, and zero unreviewed emitters. Also pass python3 tools/world_content_audit.py lights --check, python3 tools/validate.py, and git diff --check.
• Any useful visual diagnostics must remain optional and ignored under build/ or deployment-owned output; they are not merge or release gates.
• Release-line policy is unchanged: deliver compatible work through separate branch-native main and 1.x PRs, or document explicit evidence and rationale for a single-line exception.

[github-actions]

🎉 This issue has been resolved in version 3.3.0 🎉

The release is available on:

• v3.3.0
• GitHub release

Your semantic-release bot 📦🚀