allye-pi 2.11.0 → 2.12.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 CHANGED
@@ -75,7 +75,7 @@ Pair this install with your Allye account and every new, cleared or compacted se
75
75
 
76
76
  #### Live session reporting (Claude Code only, optional)
77
77
 
78
- When paired, hooks send Allye the state of your sessions (started, working, waiting, idle, ended), the tool names in use (within about 2 seconds of the call), subagent ids and types with their outcome, the spec and task keys the session is bound to and, on by default, a short activity phrase (at most 48 characters) taken from the description or todo the agent wrote for a Bash or Agent call or its current todo, with paths, URLs, emails, IP addresses, secrets and backticked code stripped on your machine; `/allye:hooks live activity off` turns the phrases off. A small background watcher (one per session, no network use while Claude Code runs) ends the run on Allye when Claude Code is closed without a normal exit. Through the Allye MCP only `task_start` and `task_submit` bind a session to a spec or task. The subagent type, tool names, activity phrases and `allye:<action>` / spec / task keys DO leave your machine; prompts, commands, tool inputs and outputs, file paths, notification and assistant messages, transcripts, the working directory, branch names and credentials never do. Allye keeps ended runs 7 days. Control it with `/allye:hooks live off|on|status`; events, fields, the watcher and local files are in [docs/live-reporting.md](docs/live-reporting.md).
78
+ When paired, hooks send Allye the state of your sessions (started, working, waiting, idle, ended), the tool names in use (within about 2 seconds of the call), subagent ids and types with their outcome, the spec and task keys the session is bound to and, on by default, three short texts the agent wrote, each at most 140 characters: the description of a subagent dispatch, an activity phrase from a Bash or Agent call or the current todo, and the `summary:` line of a crew report, plus small numbers and keywords from the report (attempt, next step, gate, checks, finding counts). Paths, URLs, emails, IP addresses, secrets and backticked code are stripped on your machine on a best-effort basis, with no guarantee; `/allye:hooks live activity off` turns the three texts off (so does Detailed Live in the Allye app). A small background watcher (one per session, no network use while Claude Code runs) ends the run on Allye when Claude Code is closed without a normal exit. Through the Allye MCP only `task_start` and `task_submit` bind a session to a spec or task. The subagent type, tool names, the three texts and `allye:<action>` / spec / task keys DO leave your machine; prompts, commands, tool inputs and outputs, file paths, notification messages, assistant messages other than that one `summary:` line, transcripts, the working directory, branch names and credentials never do. Update the plugin only after the Allye API that accepts the new fields is live. Control it with `/allye:hooks live off|on|status`; events, fields, the watcher and local files are in [docs/live-reporting.md](docs/live-reporting.md).
79
79
 
80
80
  ### Codex, OpenCode
81
81
 
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "allye-pi",
3
- "version": "2.11.0",
3
+ "version": "2.12.0",
4
4
  "description": "Allye extension for Pi and OMP: the Allye bootstrap, the Bridge skill and the repository-to-project link",
5
5
  "type": "module",
6
6
  "keywords": [
@@ -96,7 +96,7 @@ role: <agent>
96
96
  task: <key | global | draft>
97
97
  status: <see the status table below>
98
98
  commit: <HEAD sha the work/review is based on | null>
99
- summary: <one or two lines>
99
+ summary: <one line, see Report lines>
100
100
  filesRead: [<paths>]
101
101
  filesChanged: [<paths>]
102
102
  evidence:
@@ -114,6 +114,17 @@ openQuestions: [<real blockers only>]
114
114
  next: <recommended action>
115
115
  ```
116
116
 
117
+ **Report lines.** The Live reporter reads these lines from the last message of a report, so write each exactly as below: at column 0 (not indented, not in a list, not bold), with the exact lowercase key, once per report. A line that is missing, repeated or malformed is simply not transmitted; nothing is read from prose.
118
+
119
+ - `summary: <one line>` — one line of at most 140 characters. Rule: summary is transmitted to Allye: generic phase and outcome only; no names, data, secrets, file or prompt content.
120
+ - `attempt: <0|1|2>` — Pilot, Navigator and Copilot.
121
+ - `next: <reviewers|pilot_correction|mothership|watcher|done>` — the reporter lowercases the value and maps `-` to `_`; other values are not transmitted.
122
+ - `gate: SHIELD_CLEAR|WATCHER_APPROVED|null` — Shield writes only `SHIELD_CLEAR`, Watcher only `WATCHER_APPROVED`.
123
+ - `checks: ok=<n> run=<n>` — Copilot: ok = reruns whose `match` is true, run = reruns executed; Watcher: ok = satisfied ACs, run = total ACs.
124
+ - `severity_counts: critical=<n> high=<n> medium=<n> low=<n> info=<n>` — Medic, Shield, Copilot and Watcher; all five keys once, in that order.
125
+
126
+ Each `<n>` is an integer 0-99 without sign, decimal point or leading zero.
127
+
117
128
  Statuses. The base set is `passed | blocked | failed | advisory`; each role uses only the values listed for it:
118
129
 
119
130
  | Role | Statuses | Meaning of the role-specific values |
@@ -66,6 +66,7 @@ Your rights are the Architect row of `../bridge/references/delegation.md` → Al
66
66
  role: architect
67
67
  mode: options|author|auto|publish
68
68
  status: ready|needs-input|blocked
69
+ summary: <one line>
69
70
  options: # options mode
70
71
  - decision: <frontier decision>
71
72
  A: { summary: <minimal>, tradeoffs: <text> }
@@ -93,6 +94,8 @@ filesRead: [<paths>]
93
94
  filesChanged: []
94
95
  ```
95
96
 
97
+ Report lines (`summary:` and the chip lines) follow `../bridge/references/delegation.md` → Common output.
98
+
96
99
  `ready` means both self-checks, the anchor lint and `specs.spec_validate` passed (or was skipped by the recorded unknown- or unsupported-action fallback, or deferred because the MCP or project is unavailable; any other `spec_validate` error does not count as passed) and the challenge round ended with no open CRITICAL/HIGH outside an open `[Q-NN]`. Anything else is `needs-input` (questions, Recon or challenge pending) or `blocked` (with the smallest question that would unblock it).
97
100
 
98
101
  ## Limits
@@ -69,6 +69,7 @@ No verifiable official command → `blocked`, explain what is missing and why; n
69
69
  ```yaml
70
70
  role: armorer
71
71
  status: ready|blocked
72
+ summary: <one line>
72
73
  mode: <bridge mode checked>
73
74
  cache: hit|miss|refreshed
74
75
  harness:
@@ -105,6 +106,8 @@ filesChanged: []
105
106
  next: mothership-route|human-approval
106
107
  ```
107
108
 
109
+ Report lines (`summary:` and the chip lines) follow `../bridge/references/delegation.md` → Common output.
110
+
108
111
  `filesChanged` stays empty unless an approved installation changed files; the cache file is written by the Mothership.
109
112
 
110
113
  ## Limits
@@ -50,6 +50,7 @@ task: <key>
50
50
  attempt: 0|1|2
51
51
  status: passed|blocked
52
52
  commit: <HEAD sha>
53
+ summary: <one line>
53
54
  tree: clean|+dirty [<in-scope paths>]
54
55
  reruns:
55
56
  - command: <exact declared command>
@@ -65,6 +66,8 @@ scope:
65
66
  forbiddenTouched: [<paths>]
66
67
  undeclaredCommands: [<command from the Pilot's report>]
67
68
  mcpWrites: []
69
+ checks: ok=<n> run=<n> # ok: reruns with match true; run: reruns executed
70
+ severity_counts: critical=<n> high=<n> medium=<n> low=<n> info=<n>
68
71
  findings:
69
72
  - severity: HIGH|MEDIUM|LOW|INFO
70
73
  location: <path | command>
@@ -75,6 +78,8 @@ filesChanged: []
75
78
  next: reviewers|pilot-correction|mothership
76
79
  ```
77
80
 
81
+ Report lines (`summary:` and the chip lines) follow `../bridge/references/delegation.md` → Common output.
82
+
78
83
  `passed` requires: every accepted command rerun with exit 0 (or the declared expected code) as `proof: local`, except plan-declared `ciOnly` commands recorded as `proof: ci-only` (pending CI, not passed), no out-of-scope or forbidden path, no undeclared command, and the verdict tied to the exact `HEAD` + tree state above. Any later change to the slice invalidates it.
79
84
 
80
85
  ## Limits
@@ -99,6 +99,7 @@ Your rights are the Dispatcher row of `../bridge/references/delegation.md` → A
99
99
  role: dispatcher
100
100
  mode: spec|publish|guide
101
101
  status: ready|needs-input|escalate|blocked
102
+ summary: <one line>
102
103
  questions: [{ id: 1, question: <text>, recommendation: <answer and why> }] # ≤3
103
104
  spec:
104
105
  app: <app name>
@@ -119,6 +120,8 @@ filesRead: [<paths>]
119
120
  filesChanged: [<docs/code-guide.md and approved git docs in guide mode, else empty>]
120
121
  ```
121
122
 
123
+ Report lines (`summary:` and the chip lines) follow `../bridge/references/delegation.md` → Common output.
124
+
122
125
  ## Limits
123
126
 
124
127
  Never create multi-app decompositions, branches, commits, PRs or product code, or an epic the confirmed list does not include; never make an Allye write outside `publish` mode or beyond the confirmed list, create, rename or overwrite an Allye docs page, call any other API, read credentials, make a product or architecture decision for the user, or edit any file except, in `guide` mode, `docs/code-guide.md` and, only after the user's OK through the Mothership, README.md, AGENTS.md, CLAUDE.md and docs/ARCHITECTURE.md. You have no crew file.
@@ -48,6 +48,7 @@ mode: slice|challenge|diagnose
48
48
  task: <key | global | draft>
49
49
  status: passed|blocked|advisory
50
50
  commit: <HEAD sha reviewed | null>
51
+ summary: <one line>
51
52
  criteriaCoverage:
52
53
  - anchor: AC-01
53
54
  tests: [<path:test name>]
@@ -72,9 +73,12 @@ diagnosis: { cause: <statement|null>, evidence: [<proofs>], regressionTest: <tes
72
73
  openQuestions: [<real blockers only>]
73
74
  filesRead: [<paths>]
74
75
  filesChanged: []
76
+ severity_counts: critical=<n> high=<n> medium=<n> low=<n> info=<n>
75
77
  next: shield|pilot-correction|mothership
76
78
  ```
77
79
 
80
+ Report lines (`summary:` and the chip lines) follow `../bridge/references/delegation.md` → Common output.
81
+
78
82
  `passed` (slice/global) requires zero `blocking` regressions and every in-scope criterion `covered` or `ci-pending` (listed in `ciPending`, pending CI and never counted as proven locally). In `challenge`, open CRITICAL/HIGH means `blocked` for the challenge round; it never issues an implementation gate.
79
83
 
80
84
  ## Limits
@@ -68,7 +68,7 @@ phase: stage|publish
68
68
  attempt: 0|1|2
69
69
  status: passed|blocked|failed
70
70
  commit: <base HEAD sha the work started from>
71
- summary: <docs staged or pages published>
71
+ summary: <one line>
72
72
  filesRead: [<paths>]
73
73
  filesChanged: [<paths>]
74
74
  validation:
@@ -86,6 +86,8 @@ personalReads: [{ page: <short_id>, space: <space>, role: navigator }]
86
86
  next: copilot|mothership
87
87
  ```
88
88
 
89
+ Report lines (`summary:` and the chip lines) follow `../bridge/references/delegation.md` → Common output.
90
+
89
91
  `passed` is never a gate: Copilot, Medic, Shield and Watcher still decide, and the Mothership logs every `kb` write as `external-action` and reconciles it against your packet's `mcp`.
90
92
 
91
93
  ## Limits
@@ -47,6 +47,7 @@ mode: challenge|slice|optimize
47
47
  task: <key | global | draft>
48
48
  status: passed|advisory|blocked
49
49
  commit: <HEAD sha reviewed | null>
50
+ summary: <one line>
50
51
  proposals:
51
52
  - id: OPT-01
52
53
  classification: REMOVE_NOW|SIMPLIFY_NOW|KEEP|LATER
@@ -61,6 +62,8 @@ filesChanged: []
61
62
  next: mothership|human-decision
62
63
  ```
63
64
 
65
+ Report lines (`summary:` and the chip lines) follow `../bridge/references/delegation.md` → Common output.
66
+
64
67
  `blocked` only when complexity objectively violates the spec or its scope (e.g. a non-goal implemented); the Mothership reclassifies such a finding and decides the gate. In `challenge`, an open CRITICAL/HIGH scope finding blocks the challenge round until resolved or turned into an open `[Q-NN]`.
65
68
 
66
69
  ## Limits
@@ -45,7 +45,7 @@ task: <key>
45
45
  attempt: 0|1|2
46
46
  status: passed|blocked|failed
47
47
  commit: <base HEAD sha the work started from>
48
- summary: <behavior delivered>
48
+ summary: <one line>
49
49
  filesRead: [<paths>]
50
50
  filesChanged: [<paths>]
51
51
  tddCycles:
@@ -65,7 +65,7 @@ openQuestions: [<real blockers only>]
65
65
  next: copilot
66
66
  ```
67
67
 
68
- Without TDD (mechanical change), `tddCycles` is empty and `validation` shows the proof that fits. `passed` is never a gate: Copilot, Medic and Shield still decide.
68
+ Without TDD (mechanical change), `tddCycles` is empty and `validation` shows the proof that fits. `passed` is never a gate: Copilot, Medic and Shield still decide. Report lines (`summary:` and the chip lines) follow `../bridge/references/delegation.md` → Common output.
69
69
 
70
70
  ## Limits
71
71
 
@@ -49,6 +49,7 @@ When the packet gives you another app's repo path (same project, cloned locally)
49
49
  ```yaml
50
50
  role: recon
51
51
  status: passed|blocked
52
+ summary: <one line>
52
53
  mode: launch|survey|repair|optimize|interview
53
54
  question: <the target you investigated>
54
55
  observations:
@@ -77,6 +78,8 @@ openQuestions: [<real blockers only>]
77
78
  filesChanged: []
78
79
  ```
79
80
 
81
+ Report lines (`summary:` and the chip lines) follow `../bridge/references/delegation.md` → Common output.
82
+
80
83
  `likelyCause` stays `null` unless the evidence supports it; `confidence: high` requires a reproduction or a direct code proof.
81
84
 
82
85
  ## Limits
@@ -57,6 +57,7 @@ role: shield
57
57
  mode: slice|final|challenge
58
58
  task: <key | global | draft>
59
59
  status: passed|blocked
60
+ summary: <one line>
60
61
  reviewedAt: <HEAD sha + clean|+dirty | null for challenge>
61
62
  findings:
62
63
  - id: SHD-01
@@ -72,10 +73,13 @@ ciPending: [<anchors pending CI, never proven locally>]
72
73
  mcpWrites: []
73
74
  filesRead: [<paths>]
74
75
  filesChanged: []
76
+ severity_counts: critical=<n> high=<n> medium=<n> low=<n> info=<n>
75
77
  gate: SHIELD_CLEAR|null
76
78
  next: watcher|pilot-correction|mothership
77
79
  ```
78
80
 
81
+ Report lines (`summary:` and the chip lines) follow `../bridge/references/delegation.md` → Common output.
82
+
79
83
  `SHIELD_CLEAR` only in `final`, with no open CRITICAL/HIGH, no scope violation, and an explicit disposition for every other finding. `accepted-by-human` is set only when the Mothership passes a recorded human decision. Any later change to the diff invalidates the gate.
80
84
 
81
85
  ## Limits
@@ -57,6 +57,7 @@ For each section, ask: could two competent implementers read this and build diff
57
57
  role: strategist
58
58
  mode: plan|challenge
59
59
  status: passed|blocked
60
+ summary: <one line>
60
61
  spec: <SPEC-KEY | draft>
61
62
  criteriaTrace: # plan
62
63
  - anchor: AC-01
@@ -92,6 +93,8 @@ filesRead: [<paths>]
92
93
  filesChanged: []
93
94
  ```
94
95
 
96
+ Report lines (`summary:` and the chip lines) follow `../bridge/references/delegation.md` → Common output.
97
+
95
98
  `passed` in `plan` requires an acyclic DAG, every AC traced (by server tasks or `proposedTasks`), stable keys/titles, no overlapping writers in a frontier, and every command either `resolved` to an inspected script or CI target (with `ciOnly: true` and its reason when it cannot run locally) or listed as `unresolved` for the user's decision. `passed` in `challenge` requires no open CRITICAL/HIGH; it is input to the challenge round, never an implementation gate.
96
99
 
97
100
  ## Limits
@@ -48,6 +48,7 @@ role: watcher
48
48
  mode: final|scope
49
49
  task: global
50
50
  status: approved|blocked
51
+ summary: <one line>
51
52
  reviewedAt: <HEAD sha + clean|+dirty>
52
53
  traceability:
53
54
  - anchor: AC-01
@@ -71,11 +72,15 @@ findings:
71
72
  filesRead: [<paths>]
72
73
  filesChanged: []
73
74
  ciPending: [<anchors whose verdict is ci-pending>]
75
+ checks: ok=<n> run=<n> # ok: satisfied ACs; run: total ACs
76
+ severity_counts: critical=<n> high=<n> medium=<n> low=<n> info=<n>
74
77
  gate: WATCHER_APPROVED|null
75
78
  docsGate: { mode: warn|block, since: <DOCS_GATE_SINCE>, specCreated: <date>, findings: [<target or rule — gap>], blocking: true|false }
76
79
  next: mothership-check|pilot-correction
77
80
  ```
78
81
 
82
+ Report lines (`summary:` and the chip lines) follow `../bridge/references/delegation.md` → Common output.
83
+
79
84
  In `scope` mode, `approved` means `unexpected` is empty; it issues no gate. `WATCHER_APPROVED` requires every in-scope criterion `satisfied` or `ci-pending` (listed in `ciPending`), `unexpected` empty, no open finding, current evidence, and `shieldClearAt` equal to `reviewedAt`. Any other gap (`partial`, `missing`, a skipped suite not declared `ciOnly`, missing or stale evidence) blocks it. A non-empty `ciPending` means the code is approved but those anchors still wait for CI; it never counts them as proven. Any later change to the diff invalidates it.
80
85
 
81
86
  ## Docs gate