> For the complete documentation index, see [llms.txt](https://faction-os.gitbook.io/faction-os-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://faction-os.gitbook.io/faction-os-docs/.spec_system/archive/phases/phase_24/session_04_combat_playback_effects_layer.md).

# Session 04: Combat Playback Effects Layer

**Session ID**: `phase24-session04-combat-playback-effects-layer` **Package**: apps/web **Status**: Not Started **Estimated Tasks**: \~22 **Estimated Duration**: 2-4 hours

***

## Objective

Ship the effects layer that plays a linked mission's real event stream back as the battle: strikes on linked camps, counterattack flashes, combo stages, stage props for long sieges, HP drain display on plausibly-fixing events, and the verified-kill burn-down - concurrency-capped with timer cleanup.

***

## Scope

### In Scope (MVP)

* A new `pointer-events: none` effects layer component above hero tokens, mirroring the `achievementCelebration.ts` concurrency cap and timer cleanup pattern exactly.
* Strike playback: events on a `campLinks`-bound mission render as strikes on the linked camp using Session 01 classification; strikes last <= 400ms and merge into combo stages under load.
* Counterattack: `tool_result` error on a linked mission renders a hero knockback flash.
* Joint assault: concurrent linked missions strike the same camp with per-hero strike trims.
* HP drain display: plausibly-fixing events (edits/bashes) drain the linked camp's displayed HP bar; display-only, projection camp state remains scanner-derived.
* Verified camp kill: `task_verification` on a linked mission triggers the burn-down plus the existing celebration burst; the camp marker swaps to a razed state badge in reduced motion and clears on the next scan.
* Stage props: Session 01 milestones render accumulating siege props so a long fight escalates.
* Static twins: HP chip ticks plus a last-strike micro-badge replace motion effects under reduced motion.
* Tests: strike rendering from linked events only, cap and cleanup on unmount, combo stage progression, kill only on verification, no strikes from unlinked missions.

### Out of Scope

* Audio (Session 06); XP, loot, banners, kill rewards of any kind.
* Persistence regressions beyond component behavior (Session 07).

***

## Prerequisites

* [ ] Session 01 complete (strike/combo model).
* [ ] Session 02 complete (campLinks binding).
* [ ] Session 03 complete (layer conventions and anchors).

***

## Deliverables

1. Effects layer component (for example `apps/web/src/components/battlefield/EffectsLayer.tsx` with a companion pure helper) wired into `Battlefield.tsx` layer ordering.
2. Verified-kill burn-down integration with the existing celebration path.
3. Component tests covering caps, cleanup, combos, kills, and honesty.

***

## Success Criteria

* [ ] Watching a live linked mission, strike kinds visibly distinguish reading, editing, and command execution.
* [ ] Camps die only on `task_verification`; failed missions leave a scarred surviving camp.
* [ ] Effects never exceed the concurrency cap and clean up all timers on unmount.
* [ ] Reduced-motion mode conveys the same information statically.
* [ ] Web typecheck and focused tests pass.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://faction-os.gitbook.io/faction-os-docs/.spec_system/archive/phases/phase_24/session_04_combat_playback_effects_layer.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.