forge-openclaw-plugin 0.2.94 → 0.2.97
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/dist/assets/{board-D1HbyD4u.js → board-Ju0h0SeG.js} +1 -1
- package/dist/assets/index-Cn5Wpwau.css +1 -0
- package/dist/assets/{index-DWZd3qT-.js → index-CwvGs8n4.js} +55 -55
- package/dist/assets/{motion-D2OqILg_.js → motion-DRPJkN3a.js} +1 -1
- package/dist/assets/{table-YWWjPjC_.js → table-DewbFlTh.js} +1 -1
- package/dist/assets/{ui-DikPZj8S.js → ui-C2IvSrAz.js} +1 -1
- package/dist/assets/{vendor-BS9OPVNh.js → vendor-DL2K5ayT.js} +230 -225
- package/dist/index.html +7 -7
- package/dist/openclaw/tools.js +1 -1
- package/dist/server/server/src/app.js +23 -5
- package/dist/server/server/src/health.js +463 -24
- package/dist/server/server/src/openapi.js +13 -0
- package/dist/server/server/src/web.js +6 -0
- package/dist/server/src/components/ui/info-tooltip.js +7 -3
- package/openclaw.plugin.json +1 -1
- package/package.json +1 -1
- package/skills/forge-openclaw/SKILL.md +5 -4
- package/skills/forge-openclaw/entity_conversation_playbooks.md +41 -4
- package/dist/assets/index-PA_Ih223.css +0 -1
|
@@ -5178,6 +5178,8 @@ export function buildOpenApiDocument() {
|
|
|
5178
5178
|
"recentIntensityDistribution",
|
|
5179
5179
|
"dailyLoad",
|
|
5180
5180
|
"weeklyLoad",
|
|
5181
|
+
"zoneTimeSeries",
|
|
5182
|
+
"trainingIntelligence",
|
|
5181
5183
|
"activityBreakdown",
|
|
5182
5184
|
"vitalsTrend",
|
|
5183
5185
|
"sessionSignals",
|
|
@@ -5197,6 +5199,17 @@ export function buildOpenApiDocument() {
|
|
|
5197
5199
|
}),
|
|
5198
5200
|
dailyLoad: arrayOf({ type: "object", additionalProperties: true }),
|
|
5199
5201
|
weeklyLoad: arrayOf({ type: "object", additionalProperties: true }),
|
|
5202
|
+
zoneTimeSeries: {
|
|
5203
|
+
type: "object",
|
|
5204
|
+
additionalProperties: false,
|
|
5205
|
+
required: ["daily", "weekly", "monthly"],
|
|
5206
|
+
properties: {
|
|
5207
|
+
daily: arrayOf({ type: "object", additionalProperties: true }),
|
|
5208
|
+
weekly: arrayOf({ type: "object", additionalProperties: true }),
|
|
5209
|
+
monthly: arrayOf({ type: "object", additionalProperties: true })
|
|
5210
|
+
}
|
|
5211
|
+
},
|
|
5212
|
+
trainingIntelligence: { type: "object", additionalProperties: true },
|
|
5200
5213
|
activityBreakdown: arrayOf({ type: "object", additionalProperties: true }),
|
|
5201
5214
|
vitalsTrend: arrayOf({ type: "object", additionalProperties: true }),
|
|
5202
5215
|
sessionSignals: arrayOf({ type: "object", additionalProperties: true }),
|
|
@@ -270,6 +270,12 @@ async function proxyDevWebSocket(input) {
|
|
|
270
270
|
}
|
|
271
271
|
});
|
|
272
272
|
proxyRequest.on("upgrade", (response, proxySocket, proxyHead) => {
|
|
273
|
+
const closeBothSockets = () => {
|
|
274
|
+
proxySocket.destroy();
|
|
275
|
+
input.socket.destroy();
|
|
276
|
+
};
|
|
277
|
+
proxySocket.on("error", closeBothSockets);
|
|
278
|
+
input.socket.on("error", closeBothSockets);
|
|
273
279
|
writeProxyUpgradeResponse(input.socket, response);
|
|
274
280
|
if (proxyHead.length > 0) {
|
|
275
281
|
input.socket.write(proxyHead);
|
|
@@ -3,9 +3,9 @@ import { useEffect, useId, useRef, useState } from "react";
|
|
|
3
3
|
import { CircleHelp } from "lucide-react";
|
|
4
4
|
import { cn } from "../../lib/utils.js";
|
|
5
5
|
export function FieldHint({ children, className }) {
|
|
6
|
-
return _jsx("div", { className: cn("text-sm leading-6 text-white/50", className), children: children });
|
|
6
|
+
return (_jsx("div", { className: cn("text-sm leading-6 text-white/50", className), children: children }));
|
|
7
7
|
}
|
|
8
|
-
export function InfoTooltip({ content, label = "Explain this field", className }) {
|
|
8
|
+
export function InfoTooltip({ content, title, label = "Explain this field", className, panelClassName }) {
|
|
9
9
|
const [open, setOpen] = useState(false);
|
|
10
10
|
const containerRef = useRef(null);
|
|
11
11
|
const tooltipId = useId();
|
|
@@ -21,5 +21,9 @@ export function InfoTooltip({ content, label = "Explain this field", className }
|
|
|
21
21
|
document.addEventListener("pointerdown", handlePointerDown);
|
|
22
22
|
return () => document.removeEventListener("pointerdown", handlePointerDown);
|
|
23
23
|
}, [open]);
|
|
24
|
-
return (_jsxs("span", { ref: containerRef, className: cn("relative inline-flex items-center", className), onMouseEnter: () => setOpen(true), onMouseLeave: () => setOpen(false), children: [_jsx("button", { type: "button", "aria-label": label, "aria-describedby": open ? tooltipId : undefined, "aria-expanded": open, className: "inline-flex size-5 items-center justify-center rounded-full text-white/42 transition hover:bg-white/[0.06] hover:text-white/78 focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-[rgba(192,193,255,0.35)]", onFocus: () => setOpen(true), onBlur: () => setOpen(false), onClick: () => setOpen((current) => !current),
|
|
24
|
+
return (_jsxs("span", { ref: containerRef, className: cn("relative inline-flex items-center", className), onMouseEnter: () => setOpen(true), onMouseLeave: () => setOpen(false), children: [_jsx("button", { type: "button", "aria-label": label, "aria-describedby": open ? tooltipId : undefined, "aria-expanded": open, className: "inline-flex size-5 items-center justify-center rounded-full text-white/42 transition hover:bg-white/[0.06] hover:text-white/78 focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-[rgba(192,193,255,0.35)]", onFocus: () => setOpen(true), onBlur: () => setOpen(false), onClick: () => setOpen((current) => !current), onKeyDown: (event) => {
|
|
25
|
+
if (event.key === "Escape") {
|
|
26
|
+
setOpen(false);
|
|
27
|
+
}
|
|
28
|
+
}, children: _jsx(CircleHelp, { className: "size-3.5" }) }), _jsxs("span", { id: tooltipId, role: "tooltip", "aria-hidden": !open, "data-state": open ? "open" : "closed", className: cn("pointer-events-none absolute right-0 top-[calc(100%+0.55rem)] z-40 grid w-[min(20rem,calc(100vw-2.5rem))] max-w-[calc(100vw-2.5rem)] gap-1 rounded-[8px] border border-white/10 bg-[rgba(12,17,30,0.97)] px-3 py-2.5 text-left text-sm leading-6 text-white/74 shadow-[0_18px_48px_rgba(3,8,18,0.42)] transition", open ? "translate-y-0 opacity-100" : "translate-y-1 opacity-0", panelClassName), children: [title ? (_jsx("span", { className: "text-[11px] font-semibold uppercase tracking-[0.14em] text-white/58", children: title })) : null, _jsx("span", { children: content })] })] }));
|
|
25
29
|
}
|
package/openclaw.plugin.json
CHANGED
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
"id": "forge-openclaw-plugin",
|
|
3
3
|
"name": "Forge",
|
|
4
4
|
"description": "Curated OpenClaw adapter for the Forge collaboration API, UI entrypoint, and localhost auto-start runtime.",
|
|
5
|
-
"version": "0.2.
|
|
5
|
+
"version": "0.2.97",
|
|
6
6
|
"activation": {
|
|
7
7
|
"onStartup": true,
|
|
8
8
|
"onCapabilities": [
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: forge-openclaw-plugin
|
|
3
|
-
description: use when the user wants to save, search, update, review, start, stop, reward, explain, compare, or run Forge records, or when the conversation is clearly about a Forge entity or domain surface such as a goal, project, strategy, task, habit, note, wiki_page, calendar_event, calendar_connection, work_block_template, task_timebox, task_run, work_adjustment, insight, preference item, preference context, preference catalog, preference judgment, preference signal, questionnaire instrument, questionnaire run, self observation, movement, life_force, workbench, psyche_value, behavior_pattern, behavior, belief_entry, mode_profile, mode_guide_session, flashcard, trigger_report, event_type, emotion_definition, sleep_session, or
|
|
3
|
+
description: use when the user wants to save, search, update, review, start, stop, reward, explain, compare, or run Forge records, or when the conversation is clearly about a Forge entity or domain surface such as a goal, project, strategy, task, habit, note, wiki_page, calendar_event, calendar_connection, work_block_template, task_timebox, task_run, work_adjustment, insight, preference item, preference context, preference catalog, preference judgment, preference signal, questionnaire instrument, questionnaire run, self observation, movement, life_force, workbench, psyche_value, behavior_pattern, behavior, belief_entry, mode_profile, mode_guide_session, flashcard, trigger_report, event_type, emotion_definition, sleep_session, workout_session, or training_load. identify the exact Forge object or specialized surface, keep the main conversation natural, guide psyche intake with active listening before storing it, and for psyche issues that need understanding first usually begin with one exploratory question before any formulation or save suggestion.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
Forge is the user's structured system for planning work, doing work, reflecting on patterns, and keeping a truthful record of what is happening. Use it when the user is clearly working inside that system, or when they are describing something that naturally belongs there and would benefit from being stored, updated, reviewed, or acted on in Forge. Keep the conversation natural first. Do not turn every message into intake. When a real Forge entity is clearly present, name the exact entity type plainly, help with the substance of the conversation, and then offer Forge once, lightly, if storing it would genuinely help.
|
|
@@ -59,7 +59,7 @@ PM surface rule:
|
|
|
59
59
|
human/bot ownership filters.
|
|
60
60
|
- Guided modal flows handle create, edit, move, link, and closeout actions.
|
|
61
61
|
|
|
62
|
-
Forge has four major stored-entity surfaces and three specialized domain surfaces. The planning side covers goals, projects, strategies, tasks, habits, notes, calendar events, recurring work blocks, task timeboxes, live work sessions, and agent-authored insights. The Health side covers sleep sessions, sports and workout sessions, companion pairing, and habit-generated workout records that should still stay linked to the broader Forge graph. The Preferences side covers contextual taste modeling, pairwise comparisons, direct signals, editable concept libraries, and preference items that can come from Forge entities or seeded concept domains such as food, activities, places, countries, fashion, people, media, and tools. The Psyche side covers values, patterns, behaviors, beliefs, modes, guided mode sessions, flashcards, trigger reports, event types, and reusable emotion definitions. The specialized domain surfaces are Movement, Life Force, and Workbench; agents must use their dedicated route families instead of forcing them through batch CRUD. Forge also has a SQLite-backed Wiki memory layer with explicit spaces, Markdown content in database rows, backlinks, optional embeddings, and structured links back to Forge entities. Forge is also multi-user: every entity can belong to a typed `human` or `bot` user through `userId`, and read routes can scope to one or many users with `userId` or repeated `userIds`. The current access posture is configurable through a directional user graph, but the live default is still permissive: Forge can list users directly, every relationship edge starts open, and a user can read or affect another user's linked records when the route explicitly asks for them. Use `forge_get_user_directory` when owner identity or cross-user access matters. Strategies can also be locked into a contract with `isLocked`; once locked, do not mutate the graph or target structure unless the user explicitly wants the strategy unlocked first. The model should use the real entity names, not vague substitutes. Say `project`, not “initiative”. Say `behavior_pattern`, not “theme”. Say `trigger_report`, not “incident note”.
|
|
62
|
+
Forge has four major stored-entity surfaces and three specialized domain surfaces. The planning side covers goals, projects, strategies, tasks, habits, notes, calendar events, recurring work blocks, task timeboxes, live work sessions, and agent-authored insights. The Health side covers sleep sessions, sports and workout sessions, the read-only training-load surface for cardiovascular load and HR zone review, companion pairing, and habit-generated workout records that should still stay linked to the broader Forge graph. The Preferences side covers contextual taste modeling, pairwise comparisons, direct signals, editable concept libraries, and preference items that can come from Forge entities or seeded concept domains such as food, activities, places, countries, fashion, people, media, and tools. The Psyche side covers values, patterns, behaviors, beliefs, modes, guided mode sessions, flashcards, trigger reports, event types, and reusable emotion definitions. The specialized domain surfaces are Movement, Life Force, and Workbench; agents must use their dedicated route families instead of forcing them through batch CRUD. Forge also has a SQLite-backed Wiki memory layer with explicit spaces, Markdown content in database rows, backlinks, optional embeddings, and structured links back to Forge entities. Forge is also multi-user: every entity can belong to a typed `human` or `bot` user through `userId`, and read routes can scope to one or many users with `userId` or repeated `userIds`. The current access posture is configurable through a directional user graph, but the live default is still permissive: Forge can list users directly, every relationship edge starts open, and a user can read or affect another user's linked records when the route explicitly asks for them. Use `forge_get_user_directory` when owner identity or cross-user access matters. Strategies can also be locked into a contract with `isLocked`; once locked, do not mutate the graph or target structure unless the user explicitly wants the strategy unlocked first. The model should use the real entity names, not vague substitutes. Say `project`, not “initiative”. Say `behavior_pattern`, not “theme”. Say `trigger_report`, not “incident note”.
|
|
63
63
|
Habits are a first-class recurring entity in the planning side.
|
|
64
64
|
NEGATIVE HABIT CHECK-IN RULE: for a `negative` habit, the correct aligned/resisted outcome is `missed`. `missed` means the bad habit was resisted, the user stayed aligned, and the habit should award its XP bonus.
|
|
65
65
|
|
|
@@ -239,6 +239,7 @@ Entity conversation rule:
|
|
|
239
239
|
- When updating an entity, start with what is changing, what should stay true, and what prompted the update now.
|
|
240
240
|
- When enough is clear, briefly summarize what you heard in the user's own language before asking for the last missing structural detail.
|
|
241
241
|
- Treat `userId` and human/bot assignees as accountability and scope, not as opening form fields. Ask whose human or bot record it is only when ownership changes visibility, review scope, collaboration, automation behavior, or later filtering; for read requests, ask user scope only when the answer would differ across owners.
|
|
242
|
+
- Treat questionnaire runs, self-observations, reflective notes, wiki pages, sleep/workout enrichment, and preference signals as reflection-sensitive records: ask what the record should help the user understand, decide, notice, remember, or change later, then choose the right route. Do not flatten them into forms, but also do not automatically turn them into full Psyche intake unless a belief, mode, trigger report, or behavior pattern clearly emerges.
|
|
242
243
|
- The quick intake prompts later in this file are fallback checkpoints, not a script to read aloud.
|
|
243
244
|
|
|
244
245
|
Forge data location rule:
|
|
@@ -681,10 +682,10 @@ Use the health tools when the request is about sleep or sports review:
|
|
|
681
682
|
|
|
682
683
|
- `forge_get_sleep_overview` to inspect recent nights, averages, regularity, stage breakdown, and linked reflective context
|
|
683
684
|
- `forge_get_sports_overview` to inspect training volume, workout types, effort trends, habit-generated sessions, and linked context
|
|
684
|
-
- `forge_get_training_load_overview` to inspect cardiovascular load, HR zone balance, acute/chronic stress, high-intensity pressure, VO2max context, and training target fit
|
|
685
|
+
- `forge_get_training_load_overview` to inspect cardiovascular load, HR zone balance, zone-time buckets, smart training modes, acute/chronic stress, high-intensity pressure, VO2max context, next-workout guidance, and training target fit
|
|
685
686
|
- `forge_update_sleep_session` to add sleep-quality notes, tags, or links back to Forge entities after review
|
|
686
687
|
- `forge_update_workout_session` to add subjective effort, mood, meaning, tags, or links on one workout after review
|
|
687
|
-
- remember that the UI route is `/sports` while the backend overview route is `/api/v1/health/fitness`; the dedicated training-load UI is `/training-load` and its backend route is `/api/v1/health/training-load
|
|
688
|
+
- remember that the UI route is `/sports` while the backend overview route is `/api/v1/health/fitness`; the dedicated training-load UI is `/training-load` and its backend route is `/api/v1/health/training-load`, including zone-time reporting and Combat/Base/Endurance smart modes
|
|
688
689
|
|
|
689
690
|
Use these exact health batch payload shapes when the user is creating or editing the stored records themselves:
|
|
690
691
|
|
|
@@ -158,6 +158,42 @@ to the stronger container:
|
|
|
158
158
|
- Use a linked `note` when nuance should be preserved without pretending it is the
|
|
159
159
|
whole structured model.
|
|
160
160
|
|
|
161
|
+
## Reflection-sensitive non-Psyche records
|
|
162
|
+
|
|
163
|
+
Use this when the user is creating or updating a reflective record that is meaningful
|
|
164
|
+
but not necessarily a full Psyche formulation: `questionnaire_instrument`,
|
|
165
|
+
`questionnaire_run`, `self_observation`, reflective `note`, `wiki_page`,
|
|
166
|
+
`sleep_session`, `workout_session`, and some `preference_judgment` or
|
|
167
|
+
`preference_signal` moments.
|
|
168
|
+
|
|
169
|
+
- Start by asking what the reflection should help the user understand, decide,
|
|
170
|
+
notice, remember, or change later.
|
|
171
|
+
- Reflect the lived or practical stake once before asking for fields, but do not
|
|
172
|
+
over-therapize if the user is only trying to store a clear answer, note, or
|
|
173
|
+
health-context update.
|
|
174
|
+
- For questionnaire instruments, ask what kind of honest moment, review, or decision
|
|
175
|
+
the instrument should reveal before asking for item wording, scales, scoring, or
|
|
176
|
+
provenance.
|
|
177
|
+
- For questionnaire runs, ask whether the user is trying to start, continue, review,
|
|
178
|
+
or complete the run, then focus on the next answer, uncertainty, or insight that
|
|
179
|
+
changes the run. Do not turn answer collection into generic Psyche intake unless a
|
|
180
|
+
belief, mode, trigger report, or behavior pattern clearly emerges.
|
|
181
|
+
- For self-observation, keep the chain concrete: situation, cue, emotion/body,
|
|
182
|
+
thought/meaning, behavior/urge, and consequence. If that chain reveals a recurring
|
|
183
|
+
loop, belief, mode, schema theme, or one charged trigger episode, route to the
|
|
184
|
+
stronger Psyche container.
|
|
185
|
+
- For sleep and workout enrichment, ask what the user wants future review to remember:
|
|
186
|
+
recovery context, subjective effort, mood, meaning, social context, or links.
|
|
187
|
+
Preserve raw health facts through the health model and store reflection as notes,
|
|
188
|
+
tags, links, or batch updates.
|
|
189
|
+
- For notes and wiki pages, distinguish temporary operating context from durable
|
|
190
|
+
memory. A note can preserve nuance around another record; a wiki page should carry
|
|
191
|
+
reusable knowledge, source synthesis, person/context memory, or a personal manual.
|
|
192
|
+
- Route posture still matters: `questionnaire_instrument`, `note`, `sleep_session`,
|
|
193
|
+
and `workout_session` use shared batch routes for normal CRUD; `questionnaire_run`
|
|
194
|
+
uses questionnaire run actions; `self_observation` is note-backed; `wiki_page` uses
|
|
195
|
+
the wiki routes.
|
|
196
|
+
|
|
161
197
|
## Conversation arc
|
|
162
198
|
|
|
163
199
|
Most good Forge intake flows follow this sequence:
|
|
@@ -1393,10 +1429,11 @@ Route note:
|
|
|
1393
1429
|
- `sports_overview` is a read-model-only surface. Use `forge_get_sports_overview` or
|
|
1394
1430
|
`/api/v1/health/fitness` for session review. Do not create, update, or delete
|
|
1395
1431
|
`sports_overview` through batch CRUD.
|
|
1396
|
-
- For cardiovascular load, HR zone distribution,
|
|
1397
|
-
context,
|
|
1398
|
-
or
|
|
1399
|
-
|
|
1432
|
+
- For cardiovascular load, HR zone distribution, zone-time by week/month/day,
|
|
1433
|
+
acute/chronic load, VO2max context, smart training modes, 4x4 suitability,
|
|
1434
|
+
next-workout guidance, or training target questions, use
|
|
1435
|
+
`forge_get_training_load_overview` or `/api/v1/health/training-load`. Treat
|
|
1436
|
+
`training_load` as read-model-only, not a batch CRUD entity.
|
|
1400
1437
|
- If the review reveals that one workout needs reflective context, switch to the
|
|
1401
1438
|
stored `workout_session` batch route or reflective update helper for that known
|
|
1402
1439
|
session.
|