blob: bfbcb96381136f3459d5ffd2b67f9aaa4e1993b9 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
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:** DONE (commit `b180cc1`).
**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:** DONE (commit `f2e452b`).
**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.
|
