workspace: conversation.open/statusChanged carry workspaceId (1405 vitest)

- @dispatch/transport-contract 0.18.0 -> 0.19.0:
  add workspaceId: string to ConversationOpenMessage and ConversationStatusChangedMessage
- session-orchestrator: include persisted workspaceId in conversationOpened/
  conversationStatusChanged payloads
- transport-ws: forward workspaceId in WS broadcasts
- transport-http: POST /conversations/:id/open resolves workspaceId before emit
- FE handoff to 29ae: frontend-workspace-open-handoff.md

2 files changed, 106 insertions, 0 deletions

diff --git a/notes/assumptions-log.md b/notes/assumptions-log.md
new file mode 100644
index 0000000..a04467b
--- /dev/null
+++ b/notes/assumptions-log.md
@@ -0,0 +1,21 @@
+# Assumptions Log
+
+> Single place where every assumption made while the user is away is recorded.
+> These will be raised when the user returns; nothing here is final.
+
+## Task 1 — Workspace tab issue (conversation.open drops workspaceId)
+
+1. **workspaceId is always available.** `ConversationStore.getWorkspaceId(id)` returns `"default"` for unknown/unassigned conversations, so there is no `null` case to handle on the `ConversationOpenMessage`/`ConversationStatusChangedMessage` contract — a plain `string` field is sufficient. No migration or legacy row edge case changes the "default" fallback.
+2. **No transport-contract version-bump type.** Because there is no external load-time semver machinery yet (restructure-plan §2.9: "the type system IS the version check" for internal consumers), I will bump `@dispatch/transport-contract` with a **minor (additive)** version increase. The exact number is for changelog communications, not mechanics; my target is `0.19.0` based on the current `0.18.0` plus an additive surface change.
+3. **No conversation-store change required.** The store surface already exports `getWorkspaceId`; we can look it up from transport-http / session-orchestrator as needed.
+4. **Both `conversation.open` and `conversation.statusChanged` get the same additive `workspaceId: string` field**, and both broadcast paths are fixed in this task. The handoff says "same bug on conversation.statusChanged path."
+5. **Frontend tests are the frontend's problem.** I will send a handoff with the BE contract changes and the exact `29ae` deliverables; I do not edit the frontend repo.
+
+
+## Task 2 — System context builder not loading referenced files
+
+*Assumptions will be appended here as the work progresses.*
+
+## Task 3 — Persistent provider + model selection per chat
+
+*Assumptions will be appended here as the work progresses.*
diff --git a/notes/pending-issues.md b/notes/pending-issues.md
new file mode 100644
index 0000000..7dc1022
--- /dev/null
+++ b/notes/pending-issues.md
@@ -0,0 +1,85 @@
+# Pending Issues — upcoming work
+
+> Three issues recorded for future waves. Each is marked DONE here as it ships.
+> Do NOT start any of these until the prerequisites noted per-item are met.
+
+---
+
+## 1. Workspace tab issue
+
+**Status:** PENDING — awaiting a handoff file from the user before starting.
+
+> A handoff file will be provided when we are ready to begin. Do not plan or
+> summon until it arrives — the scope + root cause are expected to come from it.
+
+---
+
+## 2. System context builder — referenced files not loaded
+
+**Status:** PENDING.
+
+**Symptom:** The system context builder does not load referenced files that live
+in the conversation's working directory. Concrete reproduction: the orchestrator
+is in a workspace pointing at `/home/tradam/projects/dispatch` and the
+conversation's working directory (cwd) is `arch-rewrite`, which contains an
+`AGENTS.md` file at its root — yet that file was NOT loaded into the system
+context. The context builder appears to miss files it should be discovering and
+injecting from the cwd.
+
+**Scope (initial hypothesis, to confirm on investigation):**
+- Which unit owns the system-context / system-prompt assembly (likely
+  `session-orchestrator` context-assembly filter chain, §3.2 of the restructure
+  plan; see `notes/system-prompt-design.md`).
+- How referenced files are discovered (cwd-aware?) and whether the discovery is
+  wired through the per-conversation cwd at all.
+- Whether this is a discovery gap (files not found) or an injection gap (found
+  but not threaded into the prompt).
+
+**Notes:**
+- This is a live-found bug — reproduce against the dev stack before assuming a
+  fix is correct.
+- The cwd resolution pipeline was recently hardened (workspace defaultCwd
+  fallthrough, relative resolution, per-turn override) — check whether the
+  context builder uses `getEffectiveCwd` or a separate/older code path.
+
+---
+
+## 3. Persistent provider + model selection per chat
+
+**Status:** PENDING.
+
+**Symptom:** A chat's selected provider + model is NOT persisted per
+conversation. Opening the same chat in a new browser session defaults to a
+single hardcoded/default model + provider rather than recalling the one
+originally chosen for that conversation.
+
+**Desired behavior:** The provider + model chosen for a conversation is
+persisted (per-conversation, like `cwd` and `reasoningEffort` already are) and
+restored when the conversation is reopened — including from a fresh browser
+session. New conversations still default to the global default until the user
+selects.
+
+**Scope (initial hypothesis, to confirm):**
+- Storage: `conversation-store` likely needs a new per-conversation key space
+  (mirror the `getCwd/setCwd` and `getReasoningEffort/setReasoningEffort`
+  precedents) for the selected model name (`<credential>/<model>` form per
+  GLOSSARY) — and possibly the credential/provider if model name alone is not
+  enough to re-resolve.
+- Transport: `transport-http` + `transport-ws` need GET/PUT (or WS op) endpoints
+  for the selection, mirroring the cwd/reasoning-effort endpoints.
+- Session: `session-orchestrator` resolves the per-turn model from the persisted
+  value when the request omits an explicit override (same precedence pattern as
+  reasoning effort: per-turn override → persisted → default).
+- Wire/contract: `@dispatch/transport-contract` + possibly `@dispatch/wire` get
+  additive types (version bumps).
+- FE courier: the web repo needs to send + restore the selection (couriered via
+  the user per ORCHESTRATOR §7).
+
+**Notes:**
+- Glossary check first (§1 step 2 of the golden workflow): "model name" is the
+  canonical term (`<credentialName>/<model>` form); "credential" binds a name to
+  a provider. Confirm whether we persist the model name alone (re-resolvable via
+  credential-store) or also the credential/provider.
+- Boundary decision is the USER's (§1 step 3): is this one unit
+  (`conversation-store` + transport + orchestrator) or split? Surface before
+  planning.