@chanlerdev/scorel 0.0.1 → 0.0.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +356 -69
- package/dist/index.js +4237 -1759
- package/dist/index.js.map +4 -4
- package/docs/CHANGELOG.md +62 -0
- package/docs/ROADMAP.md +93 -9
- package/docs/SHIP.md +9 -3
- package/docs/spec/channels.md +97 -100
- package/docs/spec/client.md +11 -5
- package/docs/spec/extensions.md +115 -43
- package/docs/spec/ship/S0062-npm-package-and-release-workflow.md +3 -0
- package/docs/spec/ship/S0063-ai-release-notes.md +129 -0
- package/docs/spec/ship/S0064-gui-product-intent-and-boundary.md +79 -0
- package/docs/spec/ship/S0065-gui-electron-shell-and-embedded-host.md +73 -0
- package/docs/spec/ship/S0066-gui-local-project-workspace.md +79 -0
- package/docs/spec/ship/S0067-gui-relay-device-and-remote-project-selection.md +97 -0
- package/docs/spec/ship/S0068-gui-codex-app-polish-and-e2e.md +102 -0
- package/docs/spec/ship/S0068-gui-e2e-verification.md +50 -0
- package/docs/spec/ship/S0069-gui-codex-ui-refactor.md +371 -0
- package/docs/spec/ship/S0070-gui-streaming-and-tool-blocks.md +202 -0
- package/docs/spec/ship/S0071-gui-visual-fidelity-and-settings-shell.md +360 -0
- package/docs/spec/ship/S0072-gui-glass-sidebar-and-picker-anchoring.md +116 -0
- package/docs/spec/ship/S0073-provider-model-profile-contract.md +241 -0
- package/docs/spec/ship/S0074-gui-model-provider-settings-split.md +113 -0
- package/docs/spec/ship/S0075-provider-catalog-model-cards.md +93 -0
- package/docs/spec/ship/S0076-provider-modal-search-and-direct-key.md +70 -0
- package/docs/spec/ship/S0077-auxiliary-session-title-generation.md +95 -0
- package/docs/spec/ship/S0078-gui-provider-settings-forward-config-and-simplification.md +150 -0
- package/docs/spec/ship/S0079-gui-sidebar-layout-controls.md +49 -0
- package/docs/spec/ship/S0080-session-title-hook-and-gui-markdown-dark-code.md +58 -0
- package/docs/spec/ship/S0081-automatic-memory.md +117 -0
- package/docs/spec/ship/S0082-memory-journal-tool-and-idle-dream.md +107 -0
- package/docs/spec/ship/S0083-extension-manifest-and-im-channel-runtime.md +338 -0
- package/docs/spec/ship/S0084-built-in-telegram-im-extension.md +188 -0
- package/docs/spec/ship/S0085-gui-im-extension-settings.md +47 -0
- package/docs/spec/ship/S0086-auto-compact-and-session-memory.md +124 -0
- package/extensions/builtin/loopback/adapter.js +13 -0
- package/extensions/builtin/loopback/scorel.extension.json +7 -0
- package/extensions/builtin/loopback/skills/loopback/SKILL.md +7 -0
- package/extensions/builtin/telegram/adapter.d.ts +43 -0
- package/extensions/builtin/telegram/adapter.js +252 -0
- package/extensions/builtin/telegram/scorel.extension.json +7 -0
- package/extensions/builtin/telegram/skills/telegram/SKILL.md +9 -0
- package/package.json +6 -2
|
@@ -0,0 +1,95 @@
|
|
|
1
|
+
# S0077: Auxiliary Session Title Generation
|
|
2
|
+
|
|
3
|
+
## Goal
|
|
4
|
+
|
|
5
|
+
Generate a useful session title after the first chat message without blocking the
|
|
6
|
+
main assistant turn.
|
|
7
|
+
|
|
8
|
+
The title pipeline should use the configured `auxiliary` model so small metadata work
|
|
9
|
+
does not consume the user's primary/standard working model.
|
|
10
|
+
|
|
11
|
+
## Scope
|
|
12
|
+
|
|
13
|
+
### 1. Persistent title event
|
|
14
|
+
|
|
15
|
+
Add a persistent metadata event:
|
|
16
|
+
|
|
17
|
+
- `type`: `session_title_updated`;
|
|
18
|
+
- `title`: sanitized generated or user-provided title;
|
|
19
|
+
- `source`: `model` or `user`;
|
|
20
|
+
- optional `model`: selected model summary used by model generation;
|
|
21
|
+
- optional `derivedFrom`: event id and seq that the title was derived from.
|
|
22
|
+
|
|
23
|
+
The event is not part of the conversation tree and must not render as a chat turn.
|
|
24
|
+
Session summaries use the latest `session_title_updated.title`, then fall back to
|
|
25
|
+
`session_header.meta.title`, then the session id.
|
|
26
|
+
|
|
27
|
+
The event is intentionally reusable for future manual rename UX. V1 only implements
|
|
28
|
+
`source: "model"`.
|
|
29
|
+
|
|
30
|
+
### 2. Auxiliary model title generation
|
|
31
|
+
|
|
32
|
+
After the first user message in a session:
|
|
33
|
+
|
|
34
|
+
- if the session has no explicit header title and no prior title update event;
|
|
35
|
+
- start a sidecar title generation task using role `auxiliary`;
|
|
36
|
+
- do not block the main assistant runtime turn;
|
|
37
|
+
- append `session_title_updated` when generation succeeds;
|
|
38
|
+
- write diagnostics only when generation fails.
|
|
39
|
+
|
|
40
|
+
The title prompt uses only the first user message text and a small system prompt. It
|
|
41
|
+
must not use the full conversation context.
|
|
42
|
+
|
|
43
|
+
Title generation runtime must not register coding tools.
|
|
44
|
+
|
|
45
|
+
### 3. GUI/WebUI/session summary projection
|
|
46
|
+
|
|
47
|
+
Session lists and top bars should pick up title update events through existing event
|
|
48
|
+
streams and summary refresh paths. Transcript projectors ignore the event.
|
|
49
|
+
|
|
50
|
+
## Not In Scope
|
|
51
|
+
|
|
52
|
+
- Manual rename UI.
|
|
53
|
+
- Title regeneration controls.
|
|
54
|
+
- Deleting title history.
|
|
55
|
+
- Streaming title generation tokens.
|
|
56
|
+
- Blocking session creation or first assistant turn on title generation.
|
|
57
|
+
|
|
58
|
+
## Acceptance Criteria
|
|
59
|
+
|
|
60
|
+
- A first user message with no existing title can append `session_title_updated`.
|
|
61
|
+
- Title generation uses the `auxiliary` role selection.
|
|
62
|
+
- Explicit `CreateSessionMeta.title` suppresses automatic title generation.
|
|
63
|
+
- Existing title update events suppress duplicate model generation.
|
|
64
|
+
- Session summaries prefer the latest title update event.
|
|
65
|
+
- GUI/WebUI transcript projectors ignore title metadata events.
|
|
66
|
+
- Future manual rename can use the same event type with `source: "user"`.
|
|
67
|
+
|
|
68
|
+
## Test Requirements
|
|
69
|
+
|
|
70
|
+
- Protocol tests cover the new persistent event shape.
|
|
71
|
+
- Session store tests cover append/load validation for title events.
|
|
72
|
+
- Daemon embedded tests cover first-message auxiliary title generation and explicit-title suppression.
|
|
73
|
+
- Session summary tests cover latest title event wins.
|
|
74
|
+
- GUI/WebUI projector tests cover ignoring title metadata events.
|
|
75
|
+
- Run focused tests plus `pnpm typecheck && pnpm test`.
|
|
76
|
+
|
|
77
|
+
## Impacted Files
|
|
78
|
+
|
|
79
|
+
- `packages/protocol/src/events.ts`
|
|
80
|
+
- `packages/protocol/src/index.test.ts`
|
|
81
|
+
- `packages/core/src/session/index.ts`
|
|
82
|
+
- `packages/core/src/session/session.test.ts`
|
|
83
|
+
- `packages/daemon/src/index.ts`
|
|
84
|
+
- `packages/daemon/src/embedded/embedded.test.ts`
|
|
85
|
+
- `packages/daemon/src/projects/sessions.ts`
|
|
86
|
+
- `apps/gui/src/renderer/chatbox/projector.ts`
|
|
87
|
+
- `apps/webui/lib/events/projector.ts`
|
|
88
|
+
- `docs/ROADMAP.md`
|
|
89
|
+
|
|
90
|
+
## Risks And Boundaries
|
|
91
|
+
|
|
92
|
+
- Title generation appends a persistent metadata event, so `currentSeq` advances.
|
|
93
|
+
- V1 should not update summary sort order solely because a model generated a title.
|
|
94
|
+
- If auxiliary model config is missing or invalid, the chat should continue and only a
|
|
95
|
+
diagnostic should be written.
|
|
@@ -0,0 +1,150 @@
|
|
|
1
|
+
# S0078: GUI Provider Settings Forward Config And Simplification
|
|
2
|
+
|
|
3
|
+
## Goal
|
|
4
|
+
|
|
5
|
+
Keep the GUI model settings path forward-only after the S0073 provider/model profile
|
|
6
|
+
contract:
|
|
7
|
+
|
|
8
|
+
- user config should use the current provider/model profile shape, not the old single
|
|
9
|
+
`[model]` shape;
|
|
10
|
+
- Provider and Model settings must present the user workflow, not internal config ids
|
|
11
|
+
or generated defaults. Provider model cards are the place where users select a model
|
|
12
|
+
and correct provider-reported model metadata.
|
|
13
|
+
|
|
14
|
+
The business outcome is that a user can configure real providers and choose models
|
|
15
|
+
without needing to understand Scorel's internal TOML schema or default model parameters.
|
|
16
|
+
|
|
17
|
+
## Scope
|
|
18
|
+
|
|
19
|
+
### 1. Forward config only
|
|
20
|
+
|
|
21
|
+
Scorel is still pre-release. Do not add compatibility recovery for deprecated
|
|
22
|
+
development-stage model config:
|
|
23
|
+
|
|
24
|
+
- `[model]`;
|
|
25
|
+
- `[models.*]`.
|
|
26
|
+
|
|
27
|
+
Those shapes should continue to fail through the schema path. Local user config should
|
|
28
|
+
be rewritten to the current provider/model profile structure instead of adding runtime
|
|
29
|
+
or GUI fallback logic.
|
|
30
|
+
|
|
31
|
+
### 2. Provider settings simplification
|
|
32
|
+
|
|
33
|
+
Provider settings should show only the user-facing provider fields:
|
|
34
|
+
|
|
35
|
+
- provider name;
|
|
36
|
+
- Base URL;
|
|
37
|
+
- API Key, either direct or environment-variable based;
|
|
38
|
+
- model list;
|
|
39
|
+
- per-model selection and advanced model parameters.
|
|
40
|
+
|
|
41
|
+
Internal fields such as provider id, provider type, provider protocol/API shape, and
|
|
42
|
+
provider model keys should be generated or preserved by the application and not exposed
|
|
43
|
+
as first-class controls. New Provider forms must not prefill development provider,
|
|
44
|
+
endpoint, channel, API key, or model values.
|
|
45
|
+
|
|
46
|
+
### 3. Provider-owned model selection and parameters
|
|
47
|
+
|
|
48
|
+
Provider model cards own the model lifecycle:
|
|
49
|
+
|
|
50
|
+
- a selected Provider model is the same thing as a Scorel available model;
|
|
51
|
+
- selected models can be unselected;
|
|
52
|
+
- configured models remain editable after selection;
|
|
53
|
+
- model display name, model id, context window, max tokens, reasoning, developer-role
|
|
54
|
+
support, and image-input support can be corrected from the Provider model card;
|
|
55
|
+
- model configuration opens in a modal instead of expanding inline in the model grid;
|
|
56
|
+
- new Provider models get explicit editable defaults for context window, max tokens, and
|
|
57
|
+
reasoning instead of an empty advanced panel;
|
|
58
|
+
- Provider/model ownership must be visible in the list without exposing generated ids.
|
|
59
|
+
|
|
60
|
+
### 4. Model settings simplification
|
|
61
|
+
|
|
62
|
+
Model settings should show model choices in user language:
|
|
63
|
+
|
|
64
|
+
- model name;
|
|
65
|
+
- model id;
|
|
66
|
+
- provider ownership when displaying existing models.
|
|
67
|
+
|
|
68
|
+
Do not show available-model ids or provider-model keys. Do not provide a second
|
|
69
|
+
"add available model" form on the Model page; the Model page only consumes models
|
|
70
|
+
selected from Provider settings and assigns work roles.
|
|
71
|
+
|
|
72
|
+
## Not In Scope
|
|
73
|
+
|
|
74
|
+
- Provider marketplace, pricing, ranking, routing policy, or fallback chains.
|
|
75
|
+
- OAuth or OS keychain storage.
|
|
76
|
+
- Changing runtime model selection semantics from S0073.
|
|
77
|
+
- Automatic compatibility migration for old config shapes.
|
|
78
|
+
- Deleting providers or models.
|
|
79
|
+
- Full model-generation smoke tests from the GUI. Provider and model test controls may
|
|
80
|
+
use the existing real provider catalog path until a dedicated generation-test RPC is
|
|
81
|
+
added.
|
|
82
|
+
- Exposing pi-ai compatibility switches that Scorel does not yet pass through
|
|
83
|
+
`resolvePiAiModel`.
|
|
84
|
+
- Image generation output. pi-ai exposes image input in the current `Model.input`
|
|
85
|
+
contract, but Scorel's message protocol and runtime do not yet have an image-output
|
|
86
|
+
product path.
|
|
87
|
+
|
|
88
|
+
## Acceptance Criteria
|
|
89
|
+
|
|
90
|
+
- `~/.scorel/config.toml` uses the provider/model profile contract, not `[model]`.
|
|
91
|
+
- `list_models` surfaces deprecated `[model]` / `[models.*]` config as schema errors
|
|
92
|
+
instead of compatibility recovery.
|
|
93
|
+
- Provider settings do not render provider id, provider type, provider model key,
|
|
94
|
+
or default development provider/model values.
|
|
95
|
+
- Provider model cards render user-facing configuration for model name, model id,
|
|
96
|
+
context window, max tokens, reasoning, developer-role support, and image-input
|
|
97
|
+
support.
|
|
98
|
+
- Image-input support persists through config and maps to pi-ai `Model.input`.
|
|
99
|
+
- Provider model configuration appears in a modal; opening one model does not change the
|
|
100
|
+
height of adjacent model cards.
|
|
101
|
+
- Provider settings autosave on field blur. Model configuration autosaves on field blur
|
|
102
|
+
or checkbox changes. The main Provider page does not render a separate Save Provider
|
|
103
|
+
or Test Provider button.
|
|
104
|
+
- Model test controls live next to each model's select/config controls. Passing tests
|
|
105
|
+
show a green check state; failing tests show a red cross state and a readable message
|
|
106
|
+
above the model list.
|
|
107
|
+
- A selected Provider model can be unselected, and config rendering removes the
|
|
108
|
+
corresponding available model without leaving invalid role references.
|
|
109
|
+
- Model settings uses Chinese labels for the visible workflow.
|
|
110
|
+
- Existing provider/model ownership remains visible in a readable form.
|
|
111
|
+
- GUI-created provider models do not write hidden context-window, max-token, or
|
|
112
|
+
reasoning defaults unless the user enters them in the model configuration.
|
|
113
|
+
- The Model page does not render "模型来源" or "加入可用模型"; it only assigns roles
|
|
114
|
+
from already selected models.
|
|
115
|
+
- The sidebar "New chat" action returns to the initial composer for the current or
|
|
116
|
+
fallback project and does not create a session until the user sends the first message.
|
|
117
|
+
|
|
118
|
+
## Test Requirements
|
|
119
|
+
|
|
120
|
+
- Core config test covers custom provider models without generated runtime metadata.
|
|
121
|
+
- Daemon embedded test covers `list_models` surfacing old `[model]` as a schema error.
|
|
122
|
+
- GUI renderer test covers simplified Provider and Model settings labels and hidden
|
|
123
|
+
internal fields.
|
|
124
|
+
- Core config test covers Provider model metadata updates and available-model removal.
|
|
125
|
+
- Run:
|
|
126
|
+
- `pnpm --filter @scorel/core test -- config.test.ts -t "without generated runtime metadata"`
|
|
127
|
+
- `pnpm --filter @scorel/daemon test -- embedded.test.ts -t "deprecated single model config"`
|
|
128
|
+
- `pnpm --filter @scorel/app-gui test -- gui-shell.test.tsx`
|
|
129
|
+
- `pnpm --filter @scorel/app-gui typecheck`
|
|
130
|
+
- `pnpm typecheck && pnpm test`
|
|
131
|
+
|
|
132
|
+
## Impacted Files
|
|
133
|
+
|
|
134
|
+
- `packages/core/src/config/index.ts`
|
|
135
|
+
- `packages/daemon/src/index.ts`
|
|
136
|
+
- `packages/daemon/src/embedded/embedded.test.ts`
|
|
137
|
+
- `apps/gui/src/renderer/settings/sections/ModelSection.tsx`
|
|
138
|
+
- `apps/gui/src/renderer/settings/sections/ProviderSection.tsx`
|
|
139
|
+
- `apps/gui/src/renderer/gui-shell.test.tsx`
|
|
140
|
+
- `docs/ROADMAP.md`
|
|
141
|
+
- `~/.scorel/config.toml`
|
|
142
|
+
|
|
143
|
+
## Risks And Boundaries
|
|
144
|
+
|
|
145
|
+
- Hiding advanced runtime metadata means coding tool budgets fall back to existing
|
|
146
|
+
internal defaults when the provider model does not specify a context window. That is
|
|
147
|
+
acceptable for the main Settings flow; if those values need user control, add a later
|
|
148
|
+
advanced settings spec instead of leaking them into the basic provider form.
|
|
149
|
+
- Do not add deprecated aliases, old-shape migration, or GUI fallback logic while Scorel
|
|
150
|
+
is still in forward-only pre-release development.
|
|
@@ -0,0 +1,49 @@
|
|
|
1
|
+
# S0079: GUI Sidebar Layout Controls
|
|
2
|
+
|
|
3
|
+
## Goal
|
|
4
|
+
|
|
5
|
+
Fix the GUI sidebar layout so long Project and Session titles stay inside the
|
|
6
|
+
sidebar, and add basic desktop controls for resizing and collapsing the sidebar.
|
|
7
|
+
|
|
8
|
+
## Scope
|
|
9
|
+
|
|
10
|
+
- Clip sidebar Project and Session titles to a single line with ellipsis.
|
|
11
|
+
- Prevent horizontal scrolling in the sidebar session list.
|
|
12
|
+
- Add a sidebar resize handle with bounded width.
|
|
13
|
+
- Add a macOS-style sidebar collapse button in the sidebar titlebar area.
|
|
14
|
+
- Add a matching expand button in the topbar when the sidebar is collapsed.
|
|
15
|
+
|
|
16
|
+
## Non-goals
|
|
17
|
+
|
|
18
|
+
- Persist sidebar width across app launches.
|
|
19
|
+
- Add keyboard shortcuts or menu commands.
|
|
20
|
+
- Change Host, Relay, Session JSONL, provider, or model selection behavior.
|
|
21
|
+
|
|
22
|
+
## Acceptance Criteria
|
|
23
|
+
|
|
24
|
+
- Long sidebar titles do not create a horizontal scrollbar.
|
|
25
|
+
- Session titles expose their full value through the native title tooltip.
|
|
26
|
+
- Users can drag the sidebar edge between a safe minimum and maximum width.
|
|
27
|
+
- Users can collapse and re-expand the sidebar from the window chrome area.
|
|
28
|
+
|
|
29
|
+
## Tests
|
|
30
|
+
|
|
31
|
+
- GUI rendering tests cover the sidebar collapse and resize affordances.
|
|
32
|
+
- GUI CSS contract tests cover horizontal overflow prevention and text clipping.
|
|
33
|
+
- `pnpm typecheck && pnpm test` passes.
|
|
34
|
+
|
|
35
|
+
## Impacted Files
|
|
36
|
+
|
|
37
|
+
- `apps/gui/src/renderer/App.tsx`
|
|
38
|
+
- `apps/gui/src/renderer/shell/Sidebar.tsx`
|
|
39
|
+
- `apps/gui/src/renderer/shell/ProjectTree.tsx`
|
|
40
|
+
- `apps/gui/src/renderer/workspace/Topbar.tsx`
|
|
41
|
+
- `apps/gui/src/renderer/workspace/Workspace.tsx`
|
|
42
|
+
- `apps/gui/src/renderer/styles.css`
|
|
43
|
+
- GUI renderer tests
|
|
44
|
+
|
|
45
|
+
## Risks
|
|
46
|
+
|
|
47
|
+
- Resize mouse listeners must be removed on mouseup to avoid stale global
|
|
48
|
+
handlers.
|
|
49
|
+
- Collapsed sidebar must not hide the only way to expand the sidebar again.
|
|
@@ -0,0 +1,58 @@
|
|
|
1
|
+
# S0080: Session Title Hook And GUI Markdown Dark Code
|
|
2
|
+
|
|
3
|
+
## Goal
|
|
4
|
+
|
|
5
|
+
Move automatic session title generation into a general session lifecycle hook and
|
|
6
|
+
fix GUI Markdown code block colors in dark mode.
|
|
7
|
+
|
|
8
|
+
## Scope
|
|
9
|
+
|
|
10
|
+
- Schedule title generation from an `afterUserMessage` lifecycle hook after the
|
|
11
|
+
first `user_message` has been persisted.
|
|
12
|
+
- Keep title generation on the configured `auxiliary` model.
|
|
13
|
+
- Keep title generation off the main assistant response path: it starts after
|
|
14
|
+
the first user message persists and must not wait for the assistant answer.
|
|
15
|
+
- Preserve the existing persistent `session_title_updated` event contract.
|
|
16
|
+
- Use a dark Shiki theme for GUI fenced Markdown code blocks.
|
|
17
|
+
|
|
18
|
+
## Non-goals
|
|
19
|
+
|
|
20
|
+
- Add manual rename UI.
|
|
21
|
+
- Add user-visible title regeneration controls.
|
|
22
|
+
- Build a full public extension runtime.
|
|
23
|
+
- Change WebUI Markdown rendering.
|
|
24
|
+
|
|
25
|
+
## Acceptance Criteria
|
|
26
|
+
|
|
27
|
+
- `#runUserTurn` does not directly call the title generator.
|
|
28
|
+
- The lifecycle hook is scheduled after the first user message is appended and
|
|
29
|
+
before the assistant runtime turn starts.
|
|
30
|
+
- The lifecycle hook can run concurrently with the assistant runtime, while
|
|
31
|
+
persistent JSONL appends remain serialized.
|
|
32
|
+
- The title prompt uses a dedicated system prompt and a wrapped user request so
|
|
33
|
+
the auxiliary model summarizes the request instead of answering it.
|
|
34
|
+
- The title hook still selects role `auxiliary`.
|
|
35
|
+
- GUI Markdown fenced code blocks no longer use the light GitHub Shiki theme.
|
|
36
|
+
|
|
37
|
+
## Tests
|
|
38
|
+
|
|
39
|
+
- Daemon tests cover the session lifecycle hook structure.
|
|
40
|
+
- Existing embedded daemon tests still cover auxiliary title generation.
|
|
41
|
+
- GUI tests cover dark Shiki theme selection.
|
|
42
|
+
- `pnpm typecheck && pnpm test` passes.
|
|
43
|
+
|
|
44
|
+
## Impacted Files
|
|
45
|
+
|
|
46
|
+
- `packages/daemon/src/index.ts`
|
|
47
|
+
- `packages/daemon/src/session-hooks.test.ts`
|
|
48
|
+
- `apps/gui/src/renderer/chatbox/ShikiCodeBlock.tsx`
|
|
49
|
+
- `apps/gui/src/shiki-theme.test.ts`
|
|
50
|
+
- `docs/ROADMAP.md`
|
|
51
|
+
|
|
52
|
+
## Risks
|
|
53
|
+
|
|
54
|
+
- The title generation hook must not block the assistant turn.
|
|
55
|
+
- The title generation hook must not append events concurrently with the runtime
|
|
56
|
+
loop in a way that corrupts JSONL order or sequence numbers.
|
|
57
|
+
- Dark Shiki tokens must not override the app's inline code styling outside
|
|
58
|
+
fenced code blocks.
|
|
@@ -0,0 +1,117 @@
|
|
|
1
|
+
# S0081: Automatic Memory Context And Dreaming
|
|
2
|
+
|
|
3
|
+
> Updated by [`S0082`](S0082-memory-journal-tool-and-idle-dream.md): daily is now written through the agent-owned `AppendDaily` tool, and dream consolidation runs after project idle time instead of immediately after every turn.
|
|
4
|
+
|
|
5
|
+
## Goal
|
|
6
|
+
|
|
7
|
+
Ship Scorel's first automatic memory loop:
|
|
8
|
+
|
|
9
|
+
- inject memory context into the actual LLM `messages[]` via `harness_item kind="memory"`;
|
|
10
|
+
- automatically write a short project daily entry after completed turns;
|
|
11
|
+
- automatically consolidate durable project/root memory with the configured `auxiliary` model when available;
|
|
12
|
+
- expose GUI Settings controls for memory;
|
|
13
|
+
- support the macOS standard `Command+,` shortcut to open Settings.
|
|
14
|
+
|
|
15
|
+
The business value is continuity: a new or resumed session should know recent work, stable project decisions, and cross-project user preferences without the user manually asking the agent to read notes.
|
|
16
|
+
|
|
17
|
+
## Scope
|
|
18
|
+
|
|
19
|
+
### Memory Files
|
|
20
|
+
|
|
21
|
+
Use filesystem-backed memory under the fixed user root:
|
|
22
|
+
|
|
23
|
+
```text
|
|
24
|
+
~/.scorel/memory/
|
|
25
|
+
MEMORY.md
|
|
26
|
+
projects/
|
|
27
|
+
<projectId>/
|
|
28
|
+
MEMORY.md
|
|
29
|
+
daily/
|
|
30
|
+
YYYY-MM-DD.md
|
|
31
|
+
dream-state.json
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
### Runtime Context
|
|
35
|
+
|
|
36
|
+
Memory content must enter the model through `messages[]`, not through duplicated provider-level `systemPrompt` text.
|
|
37
|
+
|
|
38
|
+
`instruction_snapshot.memory` remains a schema/diagnostic section, but S0081 does not use it to carry memory content or policy.
|
|
39
|
+
|
|
40
|
+
### Automatic Daily
|
|
41
|
+
|
|
42
|
+
After a completed turn, Scorel appends one short daily entry automatically. The entry is generated from the completed turn evidence and written by the runtime, not by relying on the main assistant to call a tool.
|
|
43
|
+
|
|
44
|
+
### Automatic Dream
|
|
45
|
+
|
|
46
|
+
When enabled, Scorel uses the `auxiliary` model after a completed turn to consolidate:
|
|
47
|
+
|
|
48
|
+
- project `MEMORY.md` from recent turn evidence and current project memory;
|
|
49
|
+
- root `MEMORY.md` only for clearly cross-project/stable preferences.
|
|
50
|
+
|
|
51
|
+
If no auxiliary model is configured or model execution fails, the main turn still succeeds; Scorel writes diagnostics and keeps daily/context memory working.
|
|
52
|
+
|
|
53
|
+
### GUI Settings
|
|
54
|
+
|
|
55
|
+
GUI Settings must expose memory controls for the selected project:
|
|
56
|
+
|
|
57
|
+
- enable memory;
|
|
58
|
+
- enable automatic daily;
|
|
59
|
+
- enable automatic project dream;
|
|
60
|
+
- enable root memory promotion.
|
|
61
|
+
|
|
62
|
+
The Settings view must be openable with `Command+,` on macOS and `Ctrl+,` elsewhere through the Electron application menu.
|
|
63
|
+
|
|
64
|
+
## Not In Scope
|
|
65
|
+
|
|
66
|
+
- Topic memory files.
|
|
67
|
+
- Semantic recall selectors.
|
|
68
|
+
- Full activity recorder.
|
|
69
|
+
- Per-turn vector search.
|
|
70
|
+
- Cloud sync.
|
|
71
|
+
- Editing memory files in GUI.
|
|
72
|
+
- Blocking the user turn on memory consolidation success.
|
|
73
|
+
|
|
74
|
+
## Acceptance Criteria
|
|
75
|
+
|
|
76
|
+
- New sessions append a hidden `harness_item kind="memory"` before the user message is assembled into context.
|
|
77
|
+
- `buildContext()` surfaces that memory harness as a `<system-reminder>` in `messages[]`.
|
|
78
|
+
- Provider `systemPrompt` does not contain root/project/daily memory contents.
|
|
79
|
+
- Completed turns automatically append to project daily when memory daily is enabled.
|
|
80
|
+
- Completed turns attempt auxiliary consolidation when automatic dream is enabled.
|
|
81
|
+
- Project `MEMORY.md` can be updated automatically from completed turn evidence.
|
|
82
|
+
- Root `MEMORY.md` can be updated only for stable global preferences, and can be disabled independently.
|
|
83
|
+
- Missing config or missing auxiliary model does not fail the user turn.
|
|
84
|
+
- GUI Settings renders a Memory section with real controls.
|
|
85
|
+
- `Command+,` / `Ctrl+,` opens GUI Settings.
|
|
86
|
+
|
|
87
|
+
## Testing Requirements
|
|
88
|
+
|
|
89
|
+
- Unit tests for memory paths, rendering, daily append, and deterministic fallback extraction.
|
|
90
|
+
- Config tests for `[memory]` parsing/rendering.
|
|
91
|
+
- Daemon tests proving memory harness injection and daily append after a completed turn.
|
|
92
|
+
- GUI render tests proving Memory Settings controls are visible.
|
|
93
|
+
- Source-level or unit test proving the Electron menu binds `CommandOrControl+,` to Settings.
|
|
94
|
+
|
|
95
|
+
## Impacted Files
|
|
96
|
+
|
|
97
|
+
- `packages/core/src/config/index.ts`
|
|
98
|
+
- `packages/core/src/memory/*`
|
|
99
|
+
- `packages/core/src/index.ts`
|
|
100
|
+
- `packages/daemon/src/index.ts`
|
|
101
|
+
- `packages/protocol/src/events.ts`
|
|
102
|
+
- `packages/protocol/src/wire.ts`
|
|
103
|
+
- `packages/client/src/index.ts`
|
|
104
|
+
- `apps/gui/src/main.ts`
|
|
105
|
+
- `apps/gui/src/main/local-host.ts`
|
|
106
|
+
- `apps/gui/src/shared/ipc.ts`
|
|
107
|
+
- `apps/gui/src/preload.ts`
|
|
108
|
+
- `apps/gui/src/renderer/App.tsx`
|
|
109
|
+
- `apps/gui/src/renderer/settings/*`
|
|
110
|
+
- tests near the changed modules
|
|
111
|
+
|
|
112
|
+
## Risks And Boundaries
|
|
113
|
+
|
|
114
|
+
- Memory can become stale. The harness reminder must tell the model to verify current code facts from the repo.
|
|
115
|
+
- Automatic memory must be best-effort. It must not fail the main user turn.
|
|
116
|
+
- Root promotion is high-risk. S0081 only promotes clearly global preferences and keeps project facts inside project memory.
|
|
117
|
+
- Daily is recent context, not source of truth. Session JSONL remains the authoritative evidence chain.
|
|
@@ -0,0 +1,107 @@
|
|
|
1
|
+
# S0082: Memory Journal Tool And Idle Dream
|
|
2
|
+
|
|
3
|
+
## Goal
|
|
4
|
+
|
|
5
|
+
Refine S0081 memory so daily is owned by the agent main loop and dream is delayed until project idle time.
|
|
6
|
+
|
|
7
|
+
The business value is better memory quality: the agent records daily evidence while it still has full task context, and the auxiliary dreamer consolidates a continuous session/project slice instead of prematurely freezing every turn.
|
|
8
|
+
|
|
9
|
+
## Scope
|
|
10
|
+
|
|
11
|
+
### AppendDaily Tool
|
|
12
|
+
|
|
13
|
+
Add a built-in `AppendDaily` tool when memory and daily are enabled.
|
|
14
|
+
|
|
15
|
+
The tool is append-only and writes to:
|
|
16
|
+
|
|
17
|
+
```text
|
|
18
|
+
~/.scorel/memory/projects/<projectId>/daily/YYYY-MM-DD.md
|
|
19
|
+
```
|
|
20
|
+
|
|
21
|
+
The model passes structured journal data:
|
|
22
|
+
|
|
23
|
+
- `summary`
|
|
24
|
+
- `completed`
|
|
25
|
+
- `decisions`
|
|
26
|
+
- `followUps`
|
|
27
|
+
- `memoryCandidates`
|
|
28
|
+
|
|
29
|
+
The daemon/core owns the actual path, date, append format, and validation. The model does not edit daily files through generic file tools.
|
|
30
|
+
|
|
31
|
+
### Prompt Contract
|
|
32
|
+
|
|
33
|
+
The baseline prompt tells the agent to call `AppendDaily` once near the end of meaningful completed work when the tool is available.
|
|
34
|
+
|
|
35
|
+
This prompt is a tool-use contract. It must not carry root/project/daily memory content. Memory content continues to enter `messages[]` through the existing hidden memory harness.
|
|
36
|
+
|
|
37
|
+
### Idle Dream
|
|
38
|
+
|
|
39
|
+
Remove per-turn dream consolidation.
|
|
40
|
+
|
|
41
|
+
After `AppendDaily` succeeds, daemon marks the project dirty and schedules dream after `memory.dreamIdleMinutes`.
|
|
42
|
+
|
|
43
|
+
Rules:
|
|
44
|
+
|
|
45
|
+
- new daily append resets the timer;
|
|
46
|
+
- `dreamIdleMinutes = 0` means run as soon as the event loop is idle, mainly for tests/debugging;
|
|
47
|
+
- dream uses the auxiliary model;
|
|
48
|
+
- dream updates project `MEMORY.md`;
|
|
49
|
+
- dream may update root `MEMORY.md` only when `promoteRoot` is enabled;
|
|
50
|
+
- dream failure never fails the user turn.
|
|
51
|
+
|
|
52
|
+
### Settings
|
|
53
|
+
|
|
54
|
+
Extend memory settings with:
|
|
55
|
+
|
|
56
|
+
```toml
|
|
57
|
+
[memory]
|
|
58
|
+
dreamIdleMinutes = 60
|
|
59
|
+
```
|
|
60
|
+
|
|
61
|
+
GUI Settings must expose the idle delay.
|
|
62
|
+
|
|
63
|
+
## Not In Scope
|
|
64
|
+
|
|
65
|
+
- Full activity recorder.
|
|
66
|
+
- Topic memory files.
|
|
67
|
+
- Vector or semantic recall.
|
|
68
|
+
- Manual dream trigger.
|
|
69
|
+
- GUI memory file editor.
|
|
70
|
+
- Persistent cross-process dream scheduler after host process exit.
|
|
71
|
+
|
|
72
|
+
## Acceptance Criteria
|
|
73
|
+
|
|
74
|
+
- `AppendDaily` is available to the main chat runtime only when memory and daily are enabled.
|
|
75
|
+
- `AppendDaily` appends structured daily content to the fixed project daily path.
|
|
76
|
+
- Completed turns no longer write daily from daemon-side `userText + assistantText` fallback.
|
|
77
|
+
- Completed turns no longer run auxiliary dream immediately.
|
|
78
|
+
- Successful `AppendDaily` schedules idle dream according to `dreamIdleMinutes`.
|
|
79
|
+
- Idle dream reads current memory and recent daily evidence, then writes project/root memory from auxiliary model output.
|
|
80
|
+
- `dreamIdleMinutes` is parsed/rendered in config and exposed in GUI Settings.
|
|
81
|
+
- Memory content still enters the LLM through `messages[]` memory harness, not provider system prompt.
|
|
82
|
+
|
|
83
|
+
## Testing Requirements
|
|
84
|
+
|
|
85
|
+
- Core tests for `AppendDaily` formatting and append-only behavior.
|
|
86
|
+
- Provider/tool schema test coverage through existing tool conversion path.
|
|
87
|
+
- Daemon test proving daily is written by `AppendDaily`.
|
|
88
|
+
- Daemon test proving idle dream updates project/root memory.
|
|
89
|
+
- GUI test proving idle delay control renders.
|
|
90
|
+
- Full `pnpm typecheck && pnpm test`.
|
|
91
|
+
|
|
92
|
+
## Impacted Files
|
|
93
|
+
|
|
94
|
+
- `packages/core/src/memory/*`
|
|
95
|
+
- `packages/core/src/config/index.ts`
|
|
96
|
+
- `packages/core/src/provider/pi-ai.ts`
|
|
97
|
+
- `packages/core/src/instructions/index.ts`
|
|
98
|
+
- `packages/daemon/src/index.ts`
|
|
99
|
+
- `packages/protocol/src/events.ts`
|
|
100
|
+
- `apps/gui/src/renderer/settings/*`
|
|
101
|
+
- tests near the changed modules
|
|
102
|
+
|
|
103
|
+
## Risks And Boundaries
|
|
104
|
+
|
|
105
|
+
- The agent may forget to call `AppendDaily`. This is acceptable for V1; the tool contract and prompt make the desired behavior explicit without daemon fabricating journal content.
|
|
106
|
+
- The idle timer is in-process. If the host exits before the timer fires, daily evidence remains durable and can be consolidated by a future manual or scheduled dream feature.
|
|
107
|
+
- Root promotion remains high-risk and must stay constrained to stable cross-project preferences.
|