@cryptolibertus/pi-peer 0.4.1 → 0.5.0
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 +1 -1
- package/package.json +1 -1
- package/src/peers/command.mjs +1 -1
- package/src/peers/goal-board.mjs +45 -5
package/README.md
CHANGED
|
@@ -58,7 +58,7 @@ Useful commands (long form and short aliases):
|
|
|
58
58
|
|
|
59
59
|
Short aliases keep common board updates terse: `/peer goals`/`/peer ls`, `/peer current`, `/peer scout`, `/peer fanout`, `/peer proposal`/`/peer propose`, `/peer take`/`/peer claim`, `/peer complete`/`/peer done`, `/peer objection`/`/peer block`, `/peer unblock`, `/peer note`, `/peer finding`, `/peer ping`/`/peer heartbeat`, `/peer drop`/`/peer release`, `/peer pass`, `/peer fail`, `/peer vote`, and `/peer close` map to the corresponding `/peer goal ...` actions.
|
|
60
60
|
|
|
61
|
-
The board is stored locally at `.pi/peer-goals.json`; outbound message snapshots are stored in `.pi/peer-messages.json` so restarted planners can still inspect disconnected historical tasks. Mutating goal-board operations take a short local lock before load/modify/save so concurrent peer appends do not drop events. `/peer send --goal <goal-id> --claim <path[,path]>` and the `peer_send` tool's `goalId`/`claimedPaths` parameters link long-running peer tasks to the board: Symphony records a task, claims overlapping write paths before dispatch, injects goal/heartbeat instructions into the peer prompt, keeps the claim alive with local heartbeats, and releases the claim after the peer returns a final response. Each goal-linked dispatch also gets a semantic work key (`goalId | lane | objective | mode | paths`) so duplicate read/review/research lanes are leased just like write paths; pass `--key <work-key>` / `workKey` for an explicit fingerprint and `--duplicate-policy allow-parallel` only when independent second opinions are intentional. The default dispatch policy is `reuse`, so a matching active work key returns the existing claim/task handle instead of starting another peer. `/peer goal fanout` turns a goal into role-specific peer lanes, while `peer_progress` reports checkpoints from an inbound long-running task. Scout suggestions are persona-aware: they surface a recommended lane (`research`, `review`, `implementation`, `coordination`, etc.), preferred roles, a safe default claim mode, a stable work key, rationale, and suppress suggestions already covered by active work keys. Empty goals
|
|
61
|
+
The board is stored locally at `.pi/peer-goals.json`; outbound message snapshots are stored in `.pi/peer-messages.json` so restarted planners can still inspect disconnected historical tasks. Mutating goal-board operations take a short local lock before load/modify/save so concurrent peer appends do not drop events. `/peer send --goal <goal-id> --claim <path[,path]>` and the `peer_send` tool's `goalId`/`claimedPaths` parameters link long-running peer tasks to the board: Symphony records a task, claims overlapping write paths before dispatch, injects goal/heartbeat instructions into the peer prompt, keeps the claim alive with local heartbeats, and releases the claim after the peer returns a final response. Each goal-linked dispatch also gets a semantic work key (`goalId | lane | objective | mode | paths`) so duplicate read/review/research lanes are leased just like write paths; pass `--key <work-key>` / `workKey` for an explicit fingerprint and `--duplicate-policy allow-parallel` only when independent second opinions are intentional. The default dispatch policy is `reuse`, so a matching active work key returns the existing claim/task handle instead of starting another peer. `/peer goal fanout` turns a goal into role-specific peer lanes, while `peer_progress` reports checkpoints from an inbound long-running task. Scout suggestions are persona-aware: they surface a recommended lane (`research`, `review`, `implementation`, `coordination`, etc.), preferred roles, a safe default claim mode, a stable work key, rationale, and suppress suggestions already covered by active work keys. `/peer scout` prints the exact work key and a copyable `claim:` command for each read-only suggestion, so idle peers can claim the same semantic lane the scout is using instead of inventing generic seed keys. Empty goals emit multiple lane-specific read-only suggestions so idle peers can self-select research, review/QA, or implementation-planning work instead of waiting for a planner to assign lanes. Lane-tagged proposals (for example `/peer goal propose <goal> "Check package contents" --lane review --key review:package-contents`) become matching scout suggestions that reuse the proposal work key, letting the next suitable peer claim or review that proposed lane and suppress duplicate suggestions while the lane is active. Active write claims conflict on overlapping paths; active semantic claims conflict on matching work keys; released, stale, or expired claims are kept visible but inactive. Completed goal-linked tasks are shown with their handoff status instead of remaining visually stuck as `running`. Claims become stale after 45 minutes without a heartbeat unless the claim or heartbeat sets `--stale-after-ms`.
|
|
62
62
|
|
|
63
63
|
Normal goal closure requires at least one current passing vote, no current failed votes, no unresolved blocking objections, and no active write claims. Open proposals are intentionally non-blocking: they let peers show initiative without freezing closure. Stale write claims no longer block closure or new overlapping claims; use `/peer goal heartbeat` to revive work after a reconnect and `--force` only when intentionally overriding the readiness gate. Goal-linked tasks validate final handoff headings (`Status`, `Files changed`, `Verification`, `Blockers/risks`, `Safe for review`); missing sections create a blocking objection while still releasing the write claim. For multi-part work, use the fan-out gate: list peers, create/reuse a goal, delegate research/review/worker lanes, and include `Fan-out used: yes/no` plus peer handles in the final answer.
|
|
64
64
|
|
package/package.json
CHANGED
package/src/peers/command.mjs
CHANGED
|
@@ -146,7 +146,7 @@ export function formatPeerHelp() {
|
|
|
146
146
|
"- `/peer goal create <objective> [--constraint <a,b>]` — start a flat shared goal board",
|
|
147
147
|
"- `/peer goal list|show [goal-id]` — inspect peer goals, active claims, blockers, proposals, and votes",
|
|
148
148
|
"- `/peer goal fanout <goal-id> <objective> --peer <id[,id]> [--path <a,b>] [--send] [--no-await]` — plan or dispatch role-specific peer lanes",
|
|
149
|
-
"- `/peer goal scout [goal-id] [--limit <n>] [--include-closed]` — read-only proactive suggestions for what peers could do next",
|
|
149
|
+
"- `/peer goal scout [goal-id] [--limit <n>] [--include-closed]` — read-only proactive suggestions with exact work keys and copyable claim commands for what peers could do next",
|
|
150
150
|
"- `/peer goal task|finding|proposal|handoff|note <goal-id> <summary> [--path <a,b>] [--lane research|review|implementation] [--status done]` — post goal-board events; lane-tagged proposals become scout suggestions peers can self-select",
|
|
151
151
|
"- `/peer goal claim <goal-id> <task> --mode read|write --path <a,b> [--key <work-key>] [--duplicate-policy error|allow-parallel] [--ttl-ms <ms>]` — lease work without hierarchy",
|
|
152
152
|
"- `/peer goal heartbeat <goal-id> <claim-event-id> [summary] [--ttl-ms <ms>] [--stale-after-ms <ms>]` — refresh a live or stale claim",
|
package/src/peers/goal-board.mjs
CHANGED
|
@@ -248,7 +248,7 @@ export function deriveGoalState(goal, options = {}) {
|
|
|
248
248
|
const failedVotes = currentVotes.filter((vote) => vote.verdict === "fail");
|
|
249
249
|
const passingVotes = currentVotes.filter((vote) => vote.verdict === "pass" || vote.verdict === "pass-with-risks");
|
|
250
250
|
const activeWriteClaims = activeClaims.filter((claim) => claim.mode === "write");
|
|
251
|
-
const tasks = events.filter((event) => event.type === "task").map(
|
|
251
|
+
const tasks = events.filter((event) => event.type === "task").map((event) => projectTaskSummary(event, events));
|
|
252
252
|
return {
|
|
253
253
|
...goal,
|
|
254
254
|
events,
|
|
@@ -291,9 +291,12 @@ export function formatPeerGoalScout(board, options = {}) {
|
|
|
291
291
|
for (const suggestion of suggestions.slice(0, limit)) {
|
|
292
292
|
const pathText = suggestion.paths?.length ? ` · paths: ${suggestion.paths.join(", ")}` : "";
|
|
293
293
|
const laneText = suggestion.recommendedLane ? ` · lane: ${suggestion.recommendedLane}${suggestion.preferredRoles?.length ? ` for ${suggestion.preferredRoles.join("/")}` : ""}${suggestion.claimMode ? ` (${suggestion.claimMode})` : ""}` : "";
|
|
294
|
-
|
|
294
|
+
const keyText = suggestion.workKey ? ` · key: ${suggestion.workKey}` : "";
|
|
295
|
+
lines.push(`- ${suggestion.priority} · ${suggestion.goalId} · ${suggestion.kind}: ${suggestion.summary}${laneText}${pathText}${keyText}`);
|
|
296
|
+
const claim = formatScoutClaimCommand(suggestion);
|
|
297
|
+
if (claim) lines.push(` claim: ${claim}`);
|
|
295
298
|
}
|
|
296
|
-
lines.push("", "Next: post one with `/peer goal propose <goal-id> <summary>` or claim
|
|
299
|
+
lines.push("", "Next: post one with `/peer goal propose <goal-id> <summary>` or claim the exact suggested lane with the printed `claim:` command/work key. Scout does not mutate the board.");
|
|
297
300
|
return lines.join("\n");
|
|
298
301
|
}
|
|
299
302
|
|
|
@@ -325,13 +328,16 @@ export function derivePeerGoalScoutSuggestions(board, options = {}) {
|
|
|
325
328
|
if (state.openProposals.length) {
|
|
326
329
|
for (const proposal of state.openProposals.filter((item) => item.lane)) {
|
|
327
330
|
const lane = normalizeLaneName(proposal.lane);
|
|
328
|
-
|
|
331
|
+
const summary = `Self-select proposed ${lane} lane: ${proposal.summary}`;
|
|
332
|
+
push("P1", "open-proposal", summary, {
|
|
329
333
|
paths: proposal.paths,
|
|
330
334
|
recommendedLane: lane,
|
|
331
335
|
preferredRoles: preferredRolesForLane(lane),
|
|
332
336
|
claimMode: "read",
|
|
333
337
|
suggestedIntent: suggestedIntentForLane(lane),
|
|
334
338
|
rationale: "A peer proposed a lane; matching idle peers can claim or review it without planner assignment.",
|
|
339
|
+
workKey: proposal.workKey || derivePeerGoalWorkKey({ goalId: goal.id, lane, objective: proposal.summary, mode: "read", paths: proposal.paths }),
|
|
340
|
+
relatedEventId: proposal.id,
|
|
335
341
|
});
|
|
336
342
|
}
|
|
337
343
|
push("P1", "open-proposal", `Triage ${state.openProposals.length} open proposal${state.openProposals.length === 1 ? "" : "s"}; claim one or resolve it if obsolete.`, { paths: uniqueEventPaths(state.openProposals) });
|
|
@@ -559,6 +565,26 @@ function projectEventSummary(event) {
|
|
|
559
565
|
});
|
|
560
566
|
}
|
|
561
567
|
|
|
568
|
+
function projectTaskSummary(task, events) {
|
|
569
|
+
const handoff = latestEvent(events.filter((event) => taskMatchesHandoff(task, event, events)));
|
|
570
|
+
const projected = projectEventSummary(task);
|
|
571
|
+
if (!handoff) return projected;
|
|
572
|
+
return stripEmpty({
|
|
573
|
+
...projected,
|
|
574
|
+
status: handoff.status || "done",
|
|
575
|
+
completedAt: handoff.at,
|
|
576
|
+
handoffEventId: handoff.id,
|
|
577
|
+
});
|
|
578
|
+
}
|
|
579
|
+
|
|
580
|
+
function taskMatchesHandoff(task, event, events) {
|
|
581
|
+
if (event.type !== "handoff" || event.at < task.at) return false;
|
|
582
|
+
if (task.taskId && event.taskId === task.taskId) return true;
|
|
583
|
+
if (event.taskId === task.id) return true;
|
|
584
|
+
if (task.taskId || event.taskId || !task.workKey || event.workKey !== task.workKey) return false;
|
|
585
|
+
return events.filter((item) => item.type === "task" && item.workKey === task.workKey).length === 1;
|
|
586
|
+
}
|
|
587
|
+
|
|
562
588
|
function projectClaimSummary(claim, events, now) {
|
|
563
589
|
const heartbeat = latestEvent(events.filter((event) => event.type === "heartbeat" && event.resolves === claim.id));
|
|
564
590
|
const lastHeartbeatAt = heartbeat?.at;
|
|
@@ -625,13 +651,27 @@ function enrichScoutSuggestion(suggestion = {}) {
|
|
|
625
651
|
claimMode,
|
|
626
652
|
suggestedIntent: cleanText(suggestion.suggestedIntent || lane.suggestedIntent),
|
|
627
653
|
rationale: cleanText(suggestion.rationale || lane.rationale),
|
|
654
|
+
relatedEventId: cleanText(suggestion.relatedEventId),
|
|
628
655
|
});
|
|
629
656
|
return stripEmpty({
|
|
630
657
|
...enriched,
|
|
631
|
-
workKey: suggestion.workKey || derivePeerGoalWorkKey({ goalId: enriched.goalId, lane: recommendedLane, objective: enriched.summary, mode: claimMode, paths: enriched.paths }),
|
|
658
|
+
workKey: normalizeWorkKey(suggestion.workKey) || derivePeerGoalWorkKey({ goalId: enriched.goalId, lane: recommendedLane, objective: enriched.summary, mode: claimMode, paths: enriched.paths }),
|
|
632
659
|
});
|
|
633
660
|
}
|
|
634
661
|
|
|
662
|
+
function formatScoutClaimCommand(suggestion = {}) {
|
|
663
|
+
if (suggestion.claimMode !== "read" || !suggestion.workKey || !suggestion.goalId || !suggestion.summary) return "";
|
|
664
|
+
const lane = suggestion.recommendedLane ? ` --lane ${shellQuote(suggestion.recommendedLane)}` : "";
|
|
665
|
+
const paths = suggestion.paths?.length ? suggestion.paths.map((path) => ` --path ${shellQuote(path)}`).join("") : "";
|
|
666
|
+
return `/peer goal claim ${shellQuote(suggestion.goalId)} ${shellQuote(suggestion.summary)} --mode read${lane} --key ${shellQuote(suggestion.workKey)}${paths}`;
|
|
667
|
+
}
|
|
668
|
+
|
|
669
|
+
function shellQuote(value) {
|
|
670
|
+
const text = String(value || "");
|
|
671
|
+
if (/^[A-Za-z0-9_./:-]+$/.test(text)) return text;
|
|
672
|
+
return `'${text.replace(/'/g, `'"'"'`)}'`;
|
|
673
|
+
}
|
|
674
|
+
|
|
635
675
|
function normalizeLaneName(value) {
|
|
636
676
|
const lane = cleanText(value).toLowerCase();
|
|
637
677
|
if (["qa", "quality", "test", "testing"].includes(lane)) return "review";
|