pi-delegation-policy 0.13.0 → 0.14.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/CHANGELOG.md +8 -0
- package/README.md +2 -2
- package/SECURITY.md +1 -1
- package/package.json +1 -1
- package/src/prompt.ts +24 -15
package/CHANGELOG.md
CHANGED
|
@@ -2,6 +2,14 @@
|
|
|
2
2
|
|
|
3
3
|
## Unreleased
|
|
4
4
|
|
|
5
|
+
## 0.14.0 - 2026-09-21
|
|
6
|
+
|
|
7
|
+
### Changed
|
|
8
|
+
|
|
9
|
+
- Put the advisor consultation rule where the main agent reads procedure. It is now step 1 of the numbered `Decision order` and has its own `Advisor consultation:` section, instead of a paragraph inside the intensity rule that the decision steps never mentioned. Consulting is still a signal, not a quota.
|
|
10
|
+
- Replace the advisor's self-assessed triggers with observable ones. "An ambiguous decision", "one that is hard to undo", "a risk the main agent cannot resolve alone" and "a substantial doubt about architecture, plan, tooling or approach" all asked the main agent to notice its own doubt, and the same paragraph offered "routine decisions need none" as the way out. The signals are now features of the work: viable approaches trade off explicit requirements; evidence supports conflicting explanations that call for different actions; or a proposed change involves destructive data operations, difficult rollback, or compatibility changes for existing consumers. Public delivery surface is deliberately not one of them, because ordinary public changes are routine.
|
|
11
|
+
- Soften the rule for decisions that belong to the user. The main agent now considers the advisor before asking when its advice could improve the options, trade-offs or recommendation it presents, rather than consulting the advisor first.
|
|
12
|
+
|
|
5
13
|
## 0.13.0 - 2026-09-20
|
|
6
14
|
|
|
7
15
|
### Added
|
package/README.md
CHANGED
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
|
|
3
3
|
A local Pi extension that helps the main agent decide **when delegation is worth it** and which exact models to use for Small, Medium, Large, and the optional Visual Design and Advisor roles. It provides guidance; it is not a subagent runner.
|
|
4
4
|
|
|
5
|
-
> **Status:** Version **0.
|
|
5
|
+
> **Status:** Version **0.14.0** is the latest published package and supports `off`, `normal`, `aggressive`, and `orchestrator`. The package peer range is Pi `>=0.84.3`; Pi `0.84.3` is the minimum supported version and Pi `0.85.1` is the explicitly checked baseline.
|
|
6
6
|
>
|
|
7
7
|
> **Docs:** [Read the documentation site](https://yivas.github.io/pi-delegation-policy/).
|
|
8
8
|
|
|
@@ -36,7 +36,7 @@ The reader's task contains only the preserved snapshot, its opaque source ID, it
|
|
|
36
36
|
|
|
37
37
|
Advisor is an optional consultation role, off by default and outside the ordinary-role minimum. It advises; it executes no work. Configure it in `/delegate` like any other role: one exact `provider/model` reference in global defaults, an optional `thinking.advisor` policy, and `null` in a session override to turn it off. The Advisor model and thinking rows close the panel after Visual Design, and `/delegate status` reports `advisor=` and `thinking-advisor=` with their provenance.
|
|
38
38
|
|
|
39
|
-
When the advisor is configured and valid, the injected policy
|
|
39
|
+
When the advisor is configured and valid, the injected policy makes consulting it step 1 of the main agent's decision order and tells it to launch `pi-delegation-policy.advisor`, the profile that ships in this package, as a normal subagent through Pi's own subagent mechanism, with the exact configured model and that role's thinking policy. The signals are features of the work rather than self-reported doubt: viable approaches trade off explicit requirements, evidence supports conflicting explanations that call for different actions, or a proposed change involves destructive data operations, difficult rollback, or compatibility changes for existing consumers. When a decision belongs to the user, the main agent considers the advisor before asking, so the question reaches the user with better options and trade-offs. These are signals, not a quota: routine decisions need no call, and nothing enforces one.
|
|
40
40
|
|
|
41
41
|
The advisor has no tools and no extensions, so it cannot read files, run commands, delegate, or reach the network. It knows only what the brief contains and answers with plain text. A brief that stands on its own carries the objective and the decision, the constraints, the current state and the relevant evidence, the options and their consequences, what was tried or is proposed and why, and the open uncertainty. It is a conversation rather than a single ruling: the main agent continues the same thread through the host's resume mechanism instead of restarting it for the same matter.
|
|
42
42
|
|
package/SECURITY.md
CHANGED
|
@@ -20,4 +20,4 @@ Include the affected version or commit, operating system, Pi version, reproducti
|
|
|
20
20
|
|
|
21
21
|
## Supported versions
|
|
22
22
|
|
|
23
|
-
Only the latest published version is supported. Version 0.
|
|
23
|
+
Only the latest published version is supported. Version 0.14.0 is the current supported release.
|
package/package.json
CHANGED
package/src/prompt.ts
CHANGED
|
@@ -53,13 +53,25 @@ const LEGACY_VISUAL_DESIGN_ROUTING_POLICY =
|
|
|
53
53
|
const ORCHESTRATOR_VISUAL_DESIGN_ROUTING_POLICY =
|
|
54
54
|
"In orchestrator, route interaction behavior, state, validation, semantic HTML changes, keyboard mechanics, ARIA behavior, authentication, permissions, persistence, test infrastructure, and behavior-test ownership to an enabled ordinary role that fits. If any eligibility condition fails, use an enabled ordinary role or split the visual portion from the broader task. The main agent retains cross-domain integration responsibility, coordination, and final acceptance, but MUST delegate transferable integration mechanics and detailed review to a capable enabled ordinary role unless a named direct-work exception applies.";
|
|
55
55
|
|
|
56
|
-
const
|
|
56
|
+
const ADVISOR_STEP =
|
|
57
|
+
"Before committing to an approach, evaluate whether an advisor's second opinion could change the choice. Use the consultation signals below; a routine decision needs no call.";
|
|
58
|
+
|
|
59
|
+
const DELEGATION_DECISION_STEPS = [
|
|
60
|
+
"Decide under the active intensity whether this work should be delegated at all.",
|
|
61
|
+
"Classify the work and determine its acceptance criteria and the evidence it needs.",
|
|
62
|
+
"If Visual Design is configured, evaluate its four eligibility conditions before any ordinary role. When all four hold and that visual portion is being delegated, Visual Design is selected first.",
|
|
63
|
+
"Otherwise select the role by task fit among enabled roles only, following the rules below.",
|
|
64
|
+
"If no enabled role can satisfy the acceptance criteria and evidence, keep the work with the main agent.",
|
|
65
|
+
"Before every delegated launch, apply the launch requirements below without omitting the model or the thinking choice.",
|
|
66
|
+
];
|
|
67
|
+
|
|
68
|
+
const ADVISOR_POLICY = `Advisor is a consultation role; it never executes work. Consider consulting before committing when viable approaches trade off explicit requirements; when evidence supports conflicting explanations that call for different actions; or when a proposed change involves destructive data operations, difficult rollback, or compatibility changes for existing consumers. Those are consultation signals, not thresholds that require a call. If a second opinion could change the decision, ask for one. Routine decisions need none. Launch it as a normal subagent with the bundled profile "pi-delegation-policy.advisor" and the exact model and thinking of its role line; do not substitute either.
|
|
57
69
|
|
|
58
70
|
The advisor knows only what you send: it cannot see this conversation, read files or use tools. Every brief must stand on its own: the objective and the decision, the constraints, the current state and the relevant evidence, including code, errors or results where they matter, the options and their consequences, what you tried or propose and why, and the uncertainty you need resolved. Separate facts from assumptions. Do not omit what it needs, and do not dump what it cannot use.
|
|
59
71
|
|
|
60
72
|
Treat it as a conversation, not a single ruling. Continue the same thread with the host's resume mechanism to clarify, challenge or go deeper: send what changed and the open question, and never restart the thread for the same matter.
|
|
61
73
|
|
|
62
|
-
Decisions that belong to the user stay with the user
|
|
74
|
+
Decisions that belong to the user stay with the user; consider consulting the advisor before asking the user when its advice could improve the options, trade-offs or recommendation you present. Weigh its advice against the evidence and check verifiable claims before relying on them, and never hand it implementation, tool-dependent checks or your own responsibility to decide. Do not seek approval for a decision already taken, and do not keep asking until it agrees: its value is spotting weak assumptions, comparing options and challenging reasoning, not acting as an authority or a formality.`;
|
|
63
75
|
|
|
64
76
|
function hasSmallMedium(enabled: readonly ModelRole[]): boolean {
|
|
65
77
|
return enabled.includes("small") && enabled.includes("medium");
|
|
@@ -203,9 +215,15 @@ export function buildDelegationPolicy(state: RuntimeState): string | undefined {
|
|
|
203
215
|
? `${VISUAL_DESIGN_POLICY}\n\n${ORCHESTRATOR_VISUAL_DESIGN_ROUTING_POLICY}`
|
|
204
216
|
: `${VISUAL_DESIGN_POLICY}\n\n${LEGACY_VISUAL_DESIGN_ROUTING_POLICY}`;
|
|
205
217
|
const advisorThinking = roleThinking(effective.thinking.advisor);
|
|
206
|
-
const
|
|
218
|
+
const advisorRoleLine = effective.advisor
|
|
207
219
|
? `\n- Advisor (optional): ${formatReference(effective.advisor)}; exact model base: ${formatLaunchModel(effective.advisor)}; pi-subagents form: ${formatThinkingLaunchModel(effective.advisor, advisorThinking)}; thinking policy: ${thinkingPolicyText(advisorThinking)}`
|
|
208
220
|
: "";
|
|
221
|
+
// The consultation rule belongs to the decision procedure, not to the intensity paragraph.
|
|
222
|
+
const advisorSection = effective.advisor ? `\n\nAdvisor consultation:\n${ADVISOR_POLICY}` : "";
|
|
223
|
+
const decisionSteps = effective.advisor
|
|
224
|
+
? [ADVISOR_STEP, ...DELEGATION_DECISION_STEPS]
|
|
225
|
+
: DELEGATION_DECISION_STEPS;
|
|
226
|
+
const decisionOrder = decisionSteps.map((step, index) => `${index + 1}. ${step}`).join("\n");
|
|
209
227
|
const roleLines = enabled
|
|
210
228
|
.map((role) => {
|
|
211
229
|
const reference = effective[role] as ModelRef;
|
|
@@ -220,19 +238,10 @@ in the order below. This block states each rule's obligation and its exceptions;
|
|
|
220
238
|
acting.
|
|
221
239
|
|
|
222
240
|
Intensity: ${effective.intensity}.
|
|
223
|
-
Intensity rule: ${intensityPolicy}${effective.uiDesign ? `\n\nVisual Design obligation:\n${visualDesignPolicy}` : ""}
|
|
241
|
+
Intensity rule: ${intensityPolicy}${effective.uiDesign ? `\n\nVisual Design obligation:\n${visualDesignPolicy}` : ""}
|
|
224
242
|
|
|
225
243
|
Decision order:
|
|
226
|
-
|
|
227
|
-
2. Classify the work and determine its acceptance criteria and the evidence it needs.
|
|
228
|
-
3. If Visual Design is configured, evaluate its four eligibility conditions before any ordinary
|
|
229
|
-
role. When all four hold and that visual portion is being delegated, Visual Design is selected
|
|
230
|
-
first.
|
|
231
|
-
4. Otherwise select the role by task fit among enabled roles only, following the rules below.
|
|
232
|
-
5. If no enabled role can satisfy the acceptance criteria and evidence, keep the work with the main
|
|
233
|
-
agent.
|
|
234
|
-
6. Before every delegated launch, apply the launch requirements below without omitting the model or
|
|
235
|
-
the thinking choice.
|
|
244
|
+
${decisionOrder}${advisorSection}
|
|
236
245
|
|
|
237
246
|
Role selection:
|
|
238
247
|
${ROLE_SELECTION_POLICY}
|
|
@@ -248,7 +257,7 @@ Launch requirements:
|
|
|
248
257
|
Before every delegated launch, name the selected role and take its exact combined provider/model base below. Choose thinking dynamically for that run from task demand, difficulty, quantity, risk, review cost, and the selected model's capabilities when the role's thinking policy is unset. A role with a fixed policy uses exactly that level for every launch and the main agent must not change it. A role with a range policy allows only a level inside its inclusive bounds. A fixed or range policy is binding: it is not an ambient launcher default and is not inherited by another role or by the main agent. Then transmit both through the launcher's per-run mechanism without changing the provider/model base. When the launcher encodes thinking as a model suffix, pass model: "provider/model:LEVEL", replacing LEVEL with that launch's level, or pass the literal level already shown in the role line. Do not omit the model or thinking choice, inherit an ambient launcher default for either, substitute an unlisted model, persist a per-run thinking choice, launch a disabled or unconfigured role, invent a role, or use a level that a bound policy or the selected model does not support.
|
|
249
258
|
|
|
250
259
|
Roles:
|
|
251
|
-
${roleLines}${uiDesign}${
|
|
260
|
+
${roleLines}${uiDesign}${advisorRoleLine}
|
|
252
261
|
|
|
253
262
|
Limits:
|
|
254
263
|
These instructions state the main agent's obligations in this session. The extension cannot enforce
|