> 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_22/session_04_camp_link_boundaries.md).

# Session 04: Camp Link Boundaries

**Session ID**: `phase22-session04-camp-link-boundaries` **Package**: apps/web **Status**: Not Started **Estimated Tasks**: \~12-25 **Estimated Duration**: 2-4 hours

***

## Objective

Add camp-to-mission linkage readiness without inventing fake quest accepts, camp progress, or camp kills.

***

## Scope

### In Scope (MVP)

* Implement pending camp-link state handling for real `{ campId, heroId, prompt, expiresAt }` inputs only.
* Bind `mission_start` to `campLinks` by `heroId + prompt`, then by the documented first-mission fallback inside the expiry window.
* Clear relevant `campLinks` on `mission_complete` and failed `mission_update` without minting XP, banners, kills, camp death, or War Tide progress.
* Handle `suggestion_update` as snapshot reconciliation only; if reliable camp coalescing is deferred, make the no-op explicit in code and tests.
* Keep ordinary idle-suggestion accepts and current codebase issue cards from becoming camp links unless a real camp caller can provide the required camp id, hero id, and verbatim prompt.
* Add tests for exact prompt binding, fallback binding, expiry behavior, link clearing, and snapshot no-progress behavior.

### Out of Scope

* Follow the explicit out-of-scope and deferred-work boundaries in the Dependencies / Notes section below.
* Do not add rendering, audio, hosted persistence, protocol changes, or a second game state authority unless this session explicitly lists that work as in scope.

***

## Dependencies / Notes

* Depends on Session 03.
* Current code facts say `codebaseIssueToCard()` exposes dismissal rather than accept/assign and `/suggestions/:suggestionId/accept` handles idle suggestions, so Phase 22 must not pretend codebase issue cards can already start camp missions.
* Out of scope: Quest Board UI changes, camp marker buttons, Quest Board filtering, camp HP burn-down, verified camp kills, combat strikes, XP, loot, and SFX.

***

## Prerequisites

* [ ] Session 03 completed and validated.

***

## Deliverables

1. Projection support for future camp buttons and linked mission playback.
2. Tests proving the linkage mechanism is ready but cannot fabricate camp progress from unrelated Quest Board actions.

***

## Success Criteria

* [ ] A mission links only from a real pending camp link or the documented same-hero fallback inside the expiry window.
* [ ] Link clearing is deterministic and does not delete unrelated pending links.
* [ ] `suggestion_update` cannot accumulate progress and cannot silently kill or reward a camp.
* [ ] No new protocol fields or UI affordances are required for Phase 22.


---

# 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_22/session_04_camp_link_boundaries.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.