Correct the Pi advice: per-agent skills are the design; per-agent extensions via adapterConfig.command

This commit is contained in:
Sam
2026-11-11 08:13:48 +11:00
parent 77014d035b
commit 47aacfd6d1
7 changed files with 802 additions and 0 deletions

View File

@@ -1576,3 +1576,232 @@ The functional test list I proposed is in the previous message — create, assig
- session: [[packs/paperclip-harness/80-sessions/rich-discovery-ready-for-tomorrow-s-tests-everything-is-runn|Rich discovery: ready-for-tomorrow-s-tests-everything-is-running-and-rebuilt 2026-11-10 10:48:39]]
- context: [[packs/paperclip-harness/20-context/ready-for-tomorrow-s-tests-everything-is-running-and-rebuilt|ready-for-tomorrow-s-tests-everything-is-running-and-rebuilt]]
- observation: [[packs/paperclip-harness/60-observations/tmp-repository-structure-and-configuration-patterns|ready-for-tomorrow-s-tests-everything-is-running-and-rebuilt repository structure and configuration patterns]]
---
## Update (2026-11-10 21:03:21)
From installed @paperclipai/adapter-pi-local invocation observed in this workspace:
- Tool set is hard-coded: `--tools read,bash,edit,write,grep,find,ls`. An agent cannot gain extra tools by installing an extension.
- Injected skills are symlinked into the shared `~/.pi/agent/skills` directory and are not cleaned up when a different agent runs; `--no-skills` is not passed. A skill installed for one agent can remain visible to others.
- Per-agent skills ARE supported via `desiredSkills` + `POST /api/agents/{id}/skills/sync`, which builds the agent-specific `--skill` directory.
- Project-local `.pi/settings.json` is unlikely to be honoured for Paperclip runs: Pi only loads it from trusted paths, `~/.pi/agent/trust.json` had 14 entries, none matching a Paperclip worktree or `~/paperclip-agents`, and worktree paths vary per task.
- Per-agent extensions would need an adapter change: per-agent config directory, `--no-skills` with an explicit skill set, and stale symlink removal.
Source docs read from `/nix/store/rg248h9sz8dylm8p6a9w9fj4zrv4sgm5-pi-coding-agent-0.82.1/lib/node_modules/pi-monorepo/docs/` (packages.md, sdk.md, skills docs) and `@paperclipai/adapter-pi-local` source.
## Evidence
- Confidence: 85%
- Reason: Concrete adapter behaviour and isolation caveats useful for future work.
---
## Update (2026-11-10 21:03:21)
- Installed Pi CLI: `/nix/store/rg248h9sz8dylm8p6a9w9fj4zrv4sgm5-pi-coding-agent-0.82.1/bin/pi`, also on PATH at `/etc/profiles/per-user/sam/bin/pi` (Nix profile).
- Monorepo layout at `<store>/lib/node_modules/pi-monorepo/` with CHANGELOG.md, dist, docs, examples, node_modules, npm-shrinkwrap.json, package.json, README.md.
- Pi settings precedence: user global `~/.pi/agent/settings.json`; project `<cwd>/.pi/settings.json` (project settings shared with team; Pi auto-installs missing packages after project is trusted). `pi install -l` / `pi remove -l` write project settings; default writes global. `pi config -l` starts in project-overrides mode with inherited global resources dimmed.
- Skills discovery order/locations (documented): `~/.pi/agent/skills/`, `~/.agents/skills/`, project `.pi/skills/`, `.agents/skills/` in cwd and ancestors (up to git root), packages (`skills/` dirs or `pi.skills` in package.json), settings `skills` array, CLI `--skill <path>` (repeatable, additive even with --no-skills). Root `.md` files discovered as individual skills in `~/.pi/agent/skills/` and `.pi/skills/`; ignored at root of `~/.agents/skills/` and project `.agents/skills/`; dirs containing SKILL.md discovered recursively. `--no-skills` disables discovery.
- Temporary trial installs: `pi -e npm:@foo/bar`, `pi -e git:github.com/user/repo`.
- Compaction defaults (docs/compaction.md): reserveTokens 16384, keepRecentTokens 20k, configurable in `~/.pi/agent/settings.json` or `<project>/.pi/settings.json`.
## Evidence
- Confidence: 85%
- Reason: Durable environment and configuration facts about installed Pi on this machine.
---
## Update (2026-11-10 21:03:21)
- Session transcripts: `~/.pi/paperclips/*.jsonl`, count 178 at time of check. Filename pattern `<ISO-timestamp>-<agentId>.jsonl`. Each file is JSONL v3; first record `{"type":"session","version":3,"id":...,"timestamp":...,"cwd":...}` followed by records like `{"type":"model_change","provider":"omni","modelId":"deepseek/deeps..."}`.
- `GET /api/agents/{id}/task-sessions` returns task-to-session mapping with fields: id, companyId, agentId, adapterType (e.g. `pi_local`), taskKey, sessionParamsJson ({cwd: `/tmp/pc-sandbox-<date>/.paperclip/worktrees/<task-slug>`, sessionId: path to jsonl}).
- `runtime-state` gives current agent state; run log visible in Agents>agents UI.
- A read-only `Agents>history` panel is feasible: list sessions per agent, open transcript, link back to task. No new plumbing required.
## Detailed observations from completed turn
Advice only — nothing built. Written into `docs/PLAN-INTERFACE.md` as well.
## Your picker, and what it actually writes
`pi-config` registers five commands — `/config-add`, `/config-remove`, `/config-list`, `/config-show`, `/config-setup` — and `picker.ts` is the overlay: a filtered list of `~/.agents/skills` and `~/.agents/extensions` showing which are active in the project and which are active globally.
What the commands change is plain JSON:
```
<project>/.pi/settings.json project settings ("-l" mode)
~/.pi/agent/settings.json global settings
```
in the shape:
```json
{"packages": [
"npm:pi-memctx",
{"source": "git:https://gitea…/pi-config", "extensions": ["extensions/pi-config/index.ts", "extensions/tavily-search/index.ts"]},
{"source": "/home/sam/.agents", "skills": ["nixos-workflow"], "extensions": []}
]}
```
So yes: **that JSON is the interface**, and anything that can write a file can compose an agent's context exactly as the picker does. The real question is which of those files Pi actually reads on a Paperclip run.
## What Paperclip actually runs
From the installed `@paperclipai/adapter-pi-local`:
```
pi --mode json --append-system-prompt <rendered>
--provider <p> --model <m> --thinking <t>
--tools read,bash,edit,write,grep,find,ls
--session ~/.pi/paperclips/<timestamp>-<agentId>.jsonl
--skill <a directory built from that agent's desired skills>
```
Four consequences:
1. **Skills are already per agent** — `desiredSkills` and `POST /api/agents/{id}/skills/sync`. That is the supported lever, and the `--skill` directory is built from it.
2. **The isolation leaks.** Injected skills are symlinked into the *shared* `~/.pi/agent/skills` and are not removed when another agent runs, and `--no-skills` is not passed. A skill one agent had can remain visible to another.
3. **The tool list is fixed** at `read,bash,edit,write,grep,find,ls`. An agent cannot gain a tool by being handed an extension.
4. **Project-local `.pi/settings.json` is unlikely to be honoured for Paperclip runs.** Pi loads project settings only from a trusted path, and `~/.pi/agent/trust.json` has 14 entries — none is a Paperclip worktree or `~/paperclip-agents`. And a worktree path changes every task (`…/worktrees/AUD-165-…`), so there is nothing stable to trust.
That is the direct answer to your "if it uses /.pi in each folder it might be possible" — it *is* possible for you at a terminal, and *not reliable* for a Paperclip-spawned Pi, for two independent reasons.
## So, honestly
- **Identity, instructions, model, budget, skills: Paperclip.** They are already per agent, and the instructions bundle at `~/.paperclip/instances/default/companies/<co>/agents/<id>/instructions/AGENTS.md` is your real per-agent context control.
- **Extensions: one global set.** There is no per-agent extension mechanism in this adapter. Pretending otherwise gives you agents whose behaviour depends on which one ran last.
- **Folder-level `.pi/settings.json`: useful for you, not for the factory.** Keep it for when you open Pi in a folder by hand.
- **If per-agent extensions are genuinely wanted**, the change belongs in the adapter — a per-agent config directory, plus `--no-skills` with an explicit set and stale links removed. That is a Paperclip feature request, not something a terminal can arrange from outside.
## Seeing the agents does give you their history
- `~/.pi/paperclips/*.jsonl` — **178 session files** here, one per run, named `<timestamp>-<agentId>.jsonl`, each the full conversation.
- `GET /api/agents/{id}/task-sessions` maps a task to its session file and working directory.
- The run log is already visible in `Agents>agents`; `runtime-state` gives current state.
So an `Agents>history` panel is feasible with no new plumbing: list an agent's sessions, open one, render the transcript, link back to the task. Read-only, and the natural next panel after your tests.
Committed as `77014d0` — documentation only, nothing in the running layout changed.
## Evidence
- Confidence: 85%
- Reason: Concrete paths, counts, and API shape for building history features.; enriched with final-answer detail because persistence should be reusable
---
## Update (2026-11-10 21:03:21)
## Structural/configuration observations (2026-11-10 21:03:21)
Advice only — nothing built. Written into `docs/PLAN-INTERFACE.md` as well.
## Your picker, and what it actually writes
`pi-config` registers five commands — `/config-add`, `/config-remove`, `/config-list`, `/config-show`, `/config-setup` — and `picker.ts` is the overlay: a filtered list of `~/.agents/skills` and `~/.agents/extensions` showing which are active in the project and which are active globally.
What the commands change is plain JSON:
```
<project>/.pi/settings.json project settings ("-l" mode)
~/.pi/agent/settings.json global settings
```
in the shape:
```json
{"packages": [
"npm:pi-memctx",
{"source": "git:https://gitea…/pi-config", "extensions": ["extensions/pi-config/index.ts", "extensions/tavily-search/index.ts"]},
{"source": "/home/sam/.agents", "skills": ["nixos-workflow"], "extensions": []}
]}
```
So yes: **that JSON is the interface**, and anything that can write a file can compose an agent's context exactly as the picker does. The real question is which of those files Pi actually reads on a Paperclip run.
## What Paperclip actually runs
From the installed `@paperclipai/adapter-pi-local`:
```
pi --mode json --append-system-prompt <rendered>
--provider <p> --model <m> --thinking <t>
--tools read,bash,edit,write,grep,find,ls
--session ~/.pi/paperclips/<timestamp>-<agentId>.jsonl
--skill <a directory built from that agent's desired skills>
```
Four consequences:
1. **Skills are already per agent** — `desiredSkills` and `POST /api/agents/{id}/skills/sync`. That is the supported lever, and the `--skill` directory is built from it.
2. **The isolation leaks.** Injected skills are symlinked into the *shared* `~/.pi/agent/skills` and are not removed when another agent runs, and `--no-skills` is not passed. A skill one agent had can remain visible to another.
3. **The tool list is fixed** at `read,bash,edit,write,grep,find,ls`. An agent cannot gain a tool by being handed an extension.
4. **Project-local `.pi/settings.json` is unlikely to be honoured for Paperclip runs.** Pi loads project settings only from a trusted path, and `~/.pi/agent/trust.json` has 14 entries — none is a Paperclip worktree or `~/paperclip-agents`. And a worktree path changes every task (`…/worktrees/AUD-165-…`), so there is nothing stable to trust.
That is the direct answer to your "if it uses /.pi in each folder it might be possible" — it *is* possible for you at a terminal, and *not reliable* for a Paperclip-spawned Pi, for two independent reasons.
## So, honestly
- **Identity, instructions, model, budget, skills: Paperclip.** They are already per agent, and the instructions bundle at `~/.paperclip/instances/default/companies/<co>/agents/<id>/instructions/AGENTS.md` is your real per-agent context control.
- **Extensions: one global set.** There is no per-agent extension mechanism in this adapter. Pretending otherwise gives you agents whose behaviour depends on which one ran last.
- **Folder-level `.pi/settings.json`: useful for you, not for the factory.** Keep it for when you open Pi in a folder by hand.
- **If per-agent extensions are genuinely wanted**, the change belongs in the adapter — a per-agent config directory, plus `--no-skills` with an explicit set and stale links removed. That is a Paperclip feature request, not something a terminal can arrange from outside.
## Seeing the agents does give you their history
- `~/.pi/paperclips/*.jsonl` — **178 session files** here, one per run, named `<timestamp>-<agentId>.jsonl`, each the full conversation.
- `GET /api/agents/{id}/task-sessions` maps a task to its session file and working directory.
- The run log is already visible in `Agents>agents`; `runtime-state` gives current state.
So an `Agents>history` panel is feasible with no new plumbing: list an agent's sessions, open one, render the transcript, link back to the task. Read-only, and the natural next panel after your tests.
Committed as `77014d0` — documentation only, nothing in the running layout changed.
## Source paths observed
- `etc/profiles/per-user/sam/bin/pi`
- `nix/store/rg248h9sz8dylm8p6a9w9fj4zrv4sgm5-pi-coding-agent-0.82.1/bin/pi`
- `nix/store/rg248h9sz8dylm8p6a9w9fj4zrv4sgm5-pi-coding-agent-0.82.1/lib/node_modules/pi-monorepo/docs/compaction.md`
- `.pi/agent/settings.json`
- `nix/store/rg248h9sz8dylm8p6a9w9fj4zrv4sgm5-pi-coding-agent-0.82.1/lib/node_modules/pi-monorepo/docs/packages.md`
- `nix/store/rg248h9sz8dylm8p6a9w9fj4zrv4sgm5-pi-coding-agent-0.82.1/lib/node_modules/pi-monorepo/docs/sdk.md`
- `github.com/user/repo`
- `.pi/agent/skills`
- `home/sam/.local/share/tuios/worktrees/office-test-1/card-t1-build-skeleton-and-13ob`
- `home/sam/.local/share/tuios/worktrees/office-test-1/card-t2-recipe-content-3yto`
- `home/sam/ai_chat/general_chat/chat_chat`
- `home/sam/ai_chat/sys_config/devops`
- `home/sam/ai_chat/sys_config/neovim_config`
- `home/sam/ai_chat/sys_config/nixos_config`
- `home/sam/paseo/projects/central_ai_llm_master`
- `home/sam/paseo/projects/drone_fire_fighting`
- `home/sam/.pi/paperclips/2026-10-16T01-58-49-725Z-403de1f7-645c-4d35-bc7e-19b01d77bacc.jsonl`
- `home/sam/paseo/projects/artemis_control`
- `tmp/pc-sandbox-2026-11-10/.paperclip/worktrees/AUD-166-add-a-changelog-entry-for-the-harness`
- `home/sam/.pi/paperclips/2026-11-10T04-55-52`
- `extensions/pi-config/index.ts`
- `extensions/tavily-search/index.ts`
- `home/sam/.agents`
- `.pi/agent/trust.json`
- `.paperclip/instances/default/companies`
## Evidence
- Confidence: 82%
- Reason: Captured factual repo structure/configuration patterns from rich discovery
## Related learned memories <!-- same-turn-2026-11-10 21:03:21 -->
- observation: [[packs/paperclip-harness/60-observations/tmp-repository-structure-and-configuration-patterns|Pi-local adapter constraints: fixed tool list and leaking skill symlinks]]
- action: [[packs/paperclip-harness/40-actions/2026-11-10-wrote-docs-ui-layout-md-and-three-live-layout-mockups|Committed docs/PLAN-INTERFACE.md advise on Paperclip vs Pi config ownership]]
- session: [[packs/paperclip-harness/80-sessions/paperclip-pi-local-adapter-config-resolution-limits-and-agen|Paperclip Pi-local adapter: config resolution limits and agent history sources]]
- session: [[packs/paperclip-harness/80-sessions/rich-discovery-pi-2026-11-10-21-03-21|Rich discovery: .pi 2026-11-10 21:03:21]]
- context: [[packs/paperclip-harness/20-context/home|.pi]]
- runbook: [[packs/paperclip-harness/70-runbooks/tmp-deployment-operations|.pi deployment operations]]