shraga 0.1.110 → 0.1.112
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 +2 -1
- package/defaults/skills/mcp-server.md +2 -0
- package/defaults/skills/platform.md +3 -0
- package/defaults/skills/self-aware.md +1 -1
- package/dist/client/assets/{index-BaZu5Ojo.js → index-Dc1ljSt3.js} +2 -2
- package/dist/client/index.html +1 -1
- package/package.json +2 -2
- package/src/mcp-stdio-bridge.ts +25 -9
- package/src/server/claude.ts +15 -2
- package/src/server/data-sync.ts +7 -10
- package/src/server/directives.ts +8 -1
- package/src/server/engine/claude-code.ts +153 -18
- package/src/server/engine/claude-resume.ts +205 -0
- package/src/server/engine/types.ts +3 -0
- package/src/server/integrity-audit.ts +117 -46
- package/src/server/sessions.ts +16 -9
- package/src/server/shraga-config.ts +3 -0
package/README.md
CHANGED
|
@@ -222,7 +222,8 @@ common ones:
|
|
|
222
222
|
|
|
223
223
|
Beyond env vars, a typed config module in your data dir declares **global MCP servers**: the tools
|
|
224
224
|
every user gets. (Per-user MCPs are added in the UI, and agent settings like model and engine live
|
|
225
|
-
in `agent-config.json`, editable from the UI
|
|
225
|
+
in `agent-config.json`, editable from the UI; `"sdkResume": true` there opts the claude-code engine into
|
|
226
|
+
SDK session resume — see `defaults/skills/platform.md`.) Shraga seeds it from a template on first run and
|
|
226
227
|
gitignores it, so you just edit the seeded file:
|
|
227
228
|
|
|
228
229
|
```ts
|
|
@@ -41,6 +41,8 @@ Add to `~/Library/Application Support/Claude/claude_desktop_config.json` (uses s
|
|
|
41
41
|
}
|
|
42
42
|
```
|
|
43
43
|
|
|
44
|
+
Optional bridge env: `MCP_BRIDGE_TIMEOUT_MS` (protocol calls, default 60s) and `MCP_BRIDGE_TOOL_TIMEOUT_MS` (`tools/call`, default 30min). Past the bound the bridge answers with a JSON-RPC error instead of hanging.
|
|
45
|
+
|
|
44
46
|
## Available MCP Tools
|
|
45
47
|
|
|
46
48
|
| Tool | Description |
|
|
@@ -43,6 +43,7 @@ Users can prefix any message with `[directives]` to override settings. Parsed se
|
|
|
43
43
|
| `effort:VALUE` | `low`, `medium`, `high`, `max` | Set reasoning effort level |
|
|
44
44
|
| `model:VALUE` | Any alias | Override model |
|
|
45
45
|
| `turns:VALUE` | Integer | Override max turns |
|
|
46
|
+
| `resume:VALUE` | `on`, `off` | claude-code engine: resume the SDK session across turns instead of re-sending the history (prompt-cache savings). Overrides agent-config `sdkResume` for this conversation |
|
|
46
47
|
|
|
47
48
|
### Examples
|
|
48
49
|
|
|
@@ -68,6 +69,8 @@ Persistent settings that apply to all messages until changed:
|
|
|
68
69
|
| Skill Discovery | On/Off | On |
|
|
69
70
|
| System Prompt | Free text appended to system prompt | Empty |
|
|
70
71
|
|
|
72
|
+
**SDK session resume (`sdkResume`, default off).** Not in the panel: set `"sdkResume": true` in `agent-config.json` (re-read every turn, no restart) or per conversation with `[resume:on]` / `PUT /api/sessions/:id/directives {"resume": true}`. When on, the claude-code engine sends the full context + history once (fresh query), then resumes that Claude Code session and sends only the new message, appending the current speaker's `user` section (every resume turn), changed context sections and messages other channels added AFTER the user text. It falls back to a fresh query — logged as `[claude] Cache: … path=fallback:<reason>` — on: `no-session`, `concurrent-run` (an earlier CLI process on the conversation, e.g. the run a steer took over, was still alive after 5s), `speaker-change` (a different person than the one whose turns the Claude Code session holds — keeps one user's private context out of another's turns; single-speaker conversations keep resuming), `engine-switch`, `account-change`, `reset`, `summary`, `history-diverged`, `drift`, `transcript-missing` (CLI cleanup removed it), `resume-failed` (the CLI couldn't load the session, e.g. "No conversation found" — retried fresh in the same turn; any other error, like a usage limit, surfaces as-is and keeps the mapping). Flag off logs `path=fresh`, a resumed turn `path=resume`.
|
|
73
|
+
|
|
71
74
|
Directives override config and persist for the session. On a session's first turn, the resolved engine/model/turns/thinking are pinned to the session — reopening it from history resumes the exact same shape even if config defaults change later.
|
|
72
75
|
|
|
73
76
|
## Thinking / Reasoning
|
|
@@ -142,7 +142,7 @@ Your behavioral config (skills, MCPs, schedules, contacts, workspace, agent-conf
|
|
|
142
142
|
- **Pull on demand**: `POST /api/data-sync/webhook` triggers a pull (GitHub webhook fires on every push)
|
|
143
143
|
- **Change history**: `data/git-log.json` (gitignored, reconstructed) contains recent commit log — read it to understand what changed and when. Also available via `GET /api/data-sync/log`
|
|
144
144
|
- **Recovery**: If data seems stale or missing, trigger a pull by restarting the service or calling the webhook
|
|
145
|
-
- **Integrity audit**: `bun run src/server/integrity-audit.ts [git-ref]`
|
|
145
|
+
- **Integrity audit**: `bun run src/server/integrity-audit.ts [git-ref] [data-dir]` checks the files that changed between a baseline commit and HEAD (unchanged files are not re-examined — widen the ref to cover older commits). Detects missing files, truncated content, degraded JSON (fewer entries in schedules/contacts/skills-defaults/api-keys), and invalid JSON (.json over 16MB is skipped with a warning). Runs automatically after every data-sync init — check logs for `[data-sync] ⚠️ DATA INTEGRITY`. Use manually when investigating suspected data loss.
|
|
146
146
|
|
|
147
147
|
### Scheduler gating
|
|
148
148
|
Schedules sync across all envs but only **execute** where `DATA_SYNC_SCHEDULER_ACTIVE=true` (prod). Inactive envs load and serve schedules with their real `enabled` flags — they just never fire them (no timers armed). Manual "run now" still works anywhere. Event triggers respect the same gate (`fireEvent` no-ops unless active) so a webhook can't double-fire across blue-green.
|