docs(adr): ADR-017 — agent-session spike re-run resolves the 10s-vs-long-compute risk (UX.24)

After the app owner enabled 'Agent session events':
- agentSessionCreateOnIssue now succeeds (status active).
- 10s risk RESOLVED: thought at t+0 → active, then a 14s no-activity gap →
 STILL active (not stale). The 10s rule is initial-ack-only; our webhook
 emits the thought synchronously like today's 👀, then the >10s async spawn
 proceeds — no architectural conflict.
- Full lifecycle derives: thought/action→active, response→complete,
 elicitation→awaitingInput, error→error (all 5 types accepted; states
 auto-derive). Maps 1:1 to the aws-samples#247 ack model.
Remaining gate for an additive channel is the per-issue-session vs
cross-issue-epic-rollup gap + Preview→GA wait, NOT a technical blocker.
Spike issues created+deleted; token scrubbed; no migration code.

Author: isadeks

docs/decisions/ADR-017-linear-agent-session-interaction.md

@@ -98,9 +98,33 @@ probes + mutation input validation, no migration code:
   ack within 10s is sufficient, which our processor can emit synchronously
   before the async spawn — same shape as today's 👀).
 
-Net: the spike de-risked reachability + the activity model and pinpointed the
-single enablement step, without committing to migration. Re-run the
-session-create + timed-activity sequence once the app is enabled.
+Net (first pass): the spike de-risked reachability + the activity model and
+pinpointed the single enablement step, without committing to migration.
+
+**Spike re-run (2026-06-17, after the app owner enabled "Agent session events")
+— the core risk is RESOLVED end-to-end:**
+
+- `agentSessionCreateOnIssue` now succeeds → session `status: active`.
+- **The 10s-vs-long-compute question is answered:** emit a `thought` at t+0
+  (status `active`), then **wait 14s with no further activity** → session
+  **stays `active`** (not stale/unresponsive). The 10s rule governs only the
+  *initial* ack; once a `thought` lands, an arbitrarily long gap before the
+  next activity is fine. ABCA's webhook can emit the `thought` synchronously
+  (exactly like today's 👀) and let the >10s async spawn proceed — **no
+  architectural conflict.**
+- **Full lifecycle derives correctly**, matching the mapping table below:
+  `thought`→active, `action`→active, `action`+result→active,
+  `response`→**complete**; on a second session `elicitation`→**awaitingInput**,
+  `error`→**error**. All five emittable types accepted; states auto-derive
+  from the last activity. (`AgentActivityContent` is a union —
+  `AgentActivityActionContent`/`…ElicitationContent`/`…ErrorContent`/etc. — so
+  each type persists as a distinct typed record.)
+
+Conclusion: the **trigger/ack half is fully validated** against the live
+Preview API. The remaining gate for an actual additive channel is unchanged —
+it's the per-issue-session vs. cross-issue-epic-rollup gap (engine stays ours)
+plus the Preview→GA stability wait, NOT any technical blocker we found. The
+spike issues were created + deleted; no migration code written.
 
 ### Why a channel, not a rewrite
 

docs/src/content/docs/decisions/Adr-017-linear-agent-session-interaction.md

@@ -102,9 +102,33 @@ probes + mutation input validation, no migration code:
   ack within 10s is sufficient, which our processor can emit synchronously
   before the async spawn — same shape as today's 👀).
 
-Net: the spike de-risked reachability + the activity model and pinpointed the
-single enablement step, without committing to migration. Re-run the
-session-create + timed-activity sequence once the app is enabled.
+Net (first pass): the spike de-risked reachability + the activity model and
+pinpointed the single enablement step, without committing to migration.
+
+**Spike re-run (2026-06-17, after the app owner enabled "Agent session events")
+— the core risk is RESOLVED end-to-end:**
+
+- `agentSessionCreateOnIssue` now succeeds → session `status: active`.
+- **The 10s-vs-long-compute question is answered:** emit a `thought` at t+0
+  (status `active`), then **wait 14s with no further activity** → session
+  **stays `active`** (not stale/unresponsive). The 10s rule governs only the
+  *initial* ack; once a `thought` lands, an arbitrarily long gap before the
+  next activity is fine. ABCA's webhook can emit the `thought` synchronously
+  (exactly like today's 👀) and let the >10s async spawn proceed — **no
+  architectural conflict.**
+- **Full lifecycle derives correctly**, matching the mapping table below:
+  `thought`→active, `action`→active, `action`+result→active,
+  `response`→**complete**; on a second session `elicitation`→**awaitingInput**,
+  `error`→**error**. All five emittable types accepted; states auto-derive
+  from the last activity. (`AgentActivityContent` is a union —
+  `AgentActivityActionContent`/`…ElicitationContent`/`…ErrorContent`/etc. — so
+  each type persists as a distinct typed record.)
+
+Conclusion: the **trigger/ack half is fully validated** against the live
+Preview API. The remaining gate for an actual additive channel is unchanged —
+it's the per-issue-session vs. cross-issue-epic-rollup gap (engine stays ours)
+plus the Preview→GA stability wait, NOT any technical blocker we found. The
+spike issues were created + deleted; no migration code written.
 
 ### Why a channel, not a rewrite