feat(end-session): wire RCA document write-back into planning-store step

Adds Step 2.4: when a session root-causes a real incident and the
project's planning store supports an incident type + rca-<date>-<slug>.md
convention, write the postmortem there via cp-cli and link affected
items via impacted/impacted_by. Skips cleanly for projects without
that convention. Adds a scoped cp_cli Bash allowlist entry.

skills/end-session/SKILL.md

@@ -4,7 +4,7 @@ description: >
   End-of-session wrap-up. Captures a session log, updates CONTEXT.md for seamless
   resumption, and refreshes project docs (README, CLAUDE.md, FUTURE.md) with anything
   that changed this session. Just run /end-session when you're done working.
-allowed-tools: Read, Edit, Write, Grep, Glob, Bash(git log *), Bash(git diff *), Bash(date *), Bash(ls *), Bash(cat *), Bash(find *), Bash(rm *), Bash(mkdir *), Bash(sed *)
+allowed-tools: Read, Edit, Write, Grep, Glob, Bash(git log *), Bash(git diff *), Bash(date *), Bash(ls *), Bash(cat *), Bash(find *), Bash(rm *), Bash(mkdir *), Bash(sed *), Bash(python3 -m lib.cp_cli *)
 ---
 
 # End-of-Session Skill
@@ -169,6 +169,32 @@ stores mislead every future session and agent that treats them as canonical.
 
 Skip this step entirely only when the project has no external planning store.
 
+### Step 2.4: RCA document write-back
+
+If this session root-caused a real incident — a bug, outage, or regression with a clear
+symptom, root cause, and fix, not just routine debugging — and the project's planning store
+supports an `incident` item type (check the store's `DATA_VALUES.md`/`CLAUDE.md` for an
+`incident` type and an `rca-<date>-<slug>.md` naming convention; most projects will not have
+this, in which case skip this step entirely):
+
+1. **Find or create the `incident` item.** Search the planning store for an existing
+   `type: incident` item covering this incident before creating a new one.
+2. **Write the full postmortem** as `rca-<date>-<slug>.md`, where `<date>` is the date the
+   incident *occurred* (not today, if determinable from git history/logs) and `<slug>` is a
+   short kebab-case description. Cover symptom, root cause, fix, and impact — this is the
+   durable narrative; the item's `CONTEXT.md` body stays a short summary.
+3. **Upload it to the `incident` item**:
+   - CP reachable: `python3 -m lib.cp_cli planner items documents put <incident-item-uuid> rca-<date>-<slug>.md --file <path>`
+   - CP unreachable but the store has a local git checkout: write the file directly under
+     `by-uuid/<incident-item-uuid>/rca-<date>-<slug>.md` there and note in CONTEXT.md that it
+     needs a commit/push.
+   - Neither: stage it in the project's offline staging dir (e.g. `local-planning/`) and
+     record the pending upload in CONTEXT.md.
+4. **Link every affected item** to the incident via the `impacted`/`impacted_by`
+   relationship verb (or whatever the store's `DATA_VALUES.md` names it) — one document on
+   the `incident` item, one relationship edge per affected item, not copies of the document.
+5. If nothing this session rises to postmortem-worthy, skip this step and say so.
+
 ---
 
 ## Phase 3: Update Project Documentation