@caupulican/pi-adaptative 0.80.51 → 0.80.53
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 +4 -0
- package/dist/core/agent-session.d.ts +6 -0
- package/dist/core/agent-session.d.ts.map +1 -1
- package/dist/core/agent-session.js +15 -0
- package/dist/core/agent-session.js.map +1 -1
- package/dist/core/resource-loader.d.ts.map +1 -1
- package/dist/core/resource-loader.js +54 -6
- package/dist/core/resource-loader.js.map +1 -1
- package/docs/docs.json +8 -0
- package/docs/index.md +2 -0
- package/docs/resources.md +178 -0
- package/docs/self-adaptation.md +68 -0
- package/examples/extensions/custom-provider-anthropic/package-lock.json +2 -2
- package/examples/extensions/custom-provider-anthropic/package.json +1 -1
- package/examples/extensions/custom-provider-gitlab-duo/package.json +1 -1
- package/examples/extensions/sandbox/package-lock.json +2 -2
- package/examples/extensions/sandbox/package.json +1 -1
- package/examples/extensions/with-deps/package-lock.json +2 -2
- package/examples/extensions/with-deps/package.json +1 -1
- package/npm-shrinkwrap.json +12 -12
- package/package.json +4 -4
|
@@ -0,0 +1,178 @@
|
|
|
1
|
+
# Resource Profiles & Library
|
|
2
|
+
|
|
3
|
+
Pi can load a wide range of resources: extensions, skills, prompt templates, themes, agents. Across different projects and situations you rarely want all of them at once. **Resource profiles** are named on/off contracts that decide what is active, and the **Resources hub** is where you register a shared catalog of resources and curate which ones each project or situation uses.
|
|
4
|
+
|
|
5
|
+
The system separates three ideas that are easy to conflate:
|
|
6
|
+
|
|
7
|
+
- **Available** — what Pi can discover (from your catalog, plus user and project directories). "What exists."
|
|
8
|
+
- **Enabled** — what is active right now, expressed as a profile. "What's on."
|
|
9
|
+
- **Installed** — a physical copy under `~/.pi/agent/…` for portability to a machine without the catalog. "A local copy."
|
|
10
|
+
|
|
11
|
+
The default workflow is *manage by enabling, not by copying*: keep one catalog as the source of truth and switch profiles per situation. Installing is a secondary path for offline/portable use.
|
|
12
|
+
|
|
13
|
+
## Table of Contents
|
|
14
|
+
|
|
15
|
+
- [The Resources hub](#the-resources-hub)
|
|
16
|
+
- [Resource profiles](#resource-profiles)
|
|
17
|
+
- [Profile files](#profile-files)
|
|
18
|
+
- [Sources: a shared catalog](#sources-a-shared-catalog)
|
|
19
|
+
- [Manage Library](#manage-library)
|
|
20
|
+
- [Profiles as situations](#profiles-as-situations)
|
|
21
|
+
- [Per-agent profiles](#per-agent-profiles)
|
|
22
|
+
- [Install at user level](#install-at-user-level)
|
|
23
|
+
- [Backup and restore](#backup-and-restore)
|
|
24
|
+
- [Precedence](#precedence)
|
|
25
|
+
|
|
26
|
+
## The Resources hub
|
|
27
|
+
|
|
28
|
+
In interactive mode, open `/settings` and choose **Resources** to reach the **Resources Hub**:
|
|
29
|
+
|
|
30
|
+
| Item | What it does |
|
|
31
|
+
|------|--------------|
|
|
32
|
+
| **Profile / Situation** | Select the active profile. |
|
|
33
|
+
| **Manage Library** | Browse everything available and toggle what the active profile allows. |
|
|
34
|
+
| **Manage Profiles / Situations** | Create, persist, or delete profile definitions. |
|
|
35
|
+
| **Sources** | Register, trust, and remove external catalog directories. |
|
|
36
|
+
|
|
37
|
+
When no source or profile exists yet, the hub surfaces a first-run nudge — **"Add your catalog directory →"** — pointing you at the setup step below.
|
|
38
|
+
|
|
39
|
+
## Resource profiles
|
|
40
|
+
|
|
41
|
+
A profile is an allow/block contract over six kinds: `extensions`, `skills`, `prompts`, `themes`, `agents`, and `tools`. Each kind takes glob-style patterns:
|
|
42
|
+
|
|
43
|
+
- **`allow`** — when non-empty, only matching resources of that kind stay available.
|
|
44
|
+
- **`block`** — removed after `allow` is applied.
|
|
45
|
+
|
|
46
|
+
Empty `allow` means "allow all of this kind." `block: ["*"]` means "none."
|
|
47
|
+
|
|
48
|
+
A profile may also bind a **model** and a **thinking level** that apply when the profile is active. Thinking is one of `off`, `minimal`, `low`, `medium`, `high`, `xhigh`. Explicit CLI flags still win over a profile's model/thinking, which in turn win over the settings default.
|
|
49
|
+
|
|
50
|
+
Profiles are stored in settings under `resourceProfiles`, and the active one(s) in `activeResourceProfile`:
|
|
51
|
+
|
|
52
|
+
```json
|
|
53
|
+
{
|
|
54
|
+
"resourceProfiles": {
|
|
55
|
+
"review": {
|
|
56
|
+
"tools": { "allow": ["read", "grep", "find", "ls", "bash"] },
|
|
57
|
+
"extensions": { "block": ["*"] }
|
|
58
|
+
}
|
|
59
|
+
},
|
|
60
|
+
"activeResourceProfile": "review"
|
|
61
|
+
}
|
|
62
|
+
```
|
|
63
|
+
|
|
64
|
+
`activeResourceProfile` accepts a single name or an array; multiple active profiles are merged. Switch the active profile any time with `/profiles`.
|
|
65
|
+
|
|
66
|
+
> The older `disabledResources` block lists still work as a simple reversible "turn these off" filter. Profiles are the richer, named, reusable form.
|
|
67
|
+
|
|
68
|
+
## Profile files
|
|
69
|
+
|
|
70
|
+
Besides inline settings, a profile can live as a standalone JSON file in `~/.pi/agent/profiles/` (or `<catalog>/profiles/` when shared through a source). The file wraps the resource contract with optional metadata:
|
|
71
|
+
|
|
72
|
+
```json
|
|
73
|
+
{
|
|
74
|
+
"name": "recon",
|
|
75
|
+
"description": "Fast read-only scout: cheap model, read tools only.",
|
|
76
|
+
"model": "anthropic/claude-haiku-4-5",
|
|
77
|
+
"thinking": "low",
|
|
78
|
+
"resources": {
|
|
79
|
+
"tools": { "allow": ["read", "grep", "find", "ls"] },
|
|
80
|
+
"extensions": { "block": ["*"] }
|
|
81
|
+
}
|
|
82
|
+
}
|
|
83
|
+
```
|
|
84
|
+
|
|
85
|
+
File-based profiles appear by name alongside settings-based ones, so they can be version-controlled in a catalog and shared across machines.
|
|
86
|
+
|
|
87
|
+
## Sources: a shared catalog
|
|
88
|
+
|
|
89
|
+
A **source** is an external directory that Pi live-scans for resources. Point it at a folder structured like this and every kind is discovered automatically:
|
|
90
|
+
|
|
91
|
+
```
|
|
92
|
+
my-catalog/
|
|
93
|
+
├── skills/
|
|
94
|
+
├── extensions/
|
|
95
|
+
├── prompts/
|
|
96
|
+
├── themes/
|
|
97
|
+
├── profiles/
|
|
98
|
+
└── agents/
|
|
99
|
+
```
|
|
100
|
+
|
|
101
|
+
To register one:
|
|
102
|
+
|
|
103
|
+
1. `/settings → Resources → Sources → Add` and point at the directory.
|
|
104
|
+
2. Confirm the **trust** prompt.
|
|
105
|
+
|
|
106
|
+
> **Security:** a source can contain executable extension code and skills that instruct the model. Pi only scans roots you have explicitly **trusted**; untrusted or missing roots are skipped. Review a catalog before trusting it.
|
|
107
|
+
|
|
108
|
+
Registered roots are stored as `externalResourceRoots`; the trusted subset as `trustedResourceRoots`. Only roots that are both trusted and present are scanned. Because the scan is live, editing a file in the catalog is reflected on the next reload — no copy step.
|
|
109
|
+
|
|
110
|
+
This makes a git repository of shared resources a natural catalog: clone it once, register it as a source, and it *is* your backup.
|
|
111
|
+
|
|
112
|
+
## Manage Library
|
|
113
|
+
|
|
114
|
+
**Manage Library** is the browser for going from "a folder of fifty things" to "this project uses these eight." It lists everything available per kind, with its source labelled (catalog vs. user vs. project), and lets you toggle each item on or off for the active profile.
|
|
115
|
+
|
|
116
|
+
- **Fuzzy search** by name or description, so you never scroll a long list.
|
|
117
|
+
- Both framings are supported: *allow only these* and *everything except these* — so you don't have to untick forty-seven items to keep three.
|
|
118
|
+
- Toggles **apply live**. Turning an extension on or off loads or unloads it in place; its tools and commands appear or disappear without restarting the session. Lighter kinds (skills, prompts, themes) refresh the same way.
|
|
119
|
+
- An item that a profile enables but that has since disappeared from the catalog is marked **`[missing]`** rather than silently dropped.
|
|
120
|
+
|
|
121
|
+
By default, changes save to the active profile at the **directory-overlay** scope — a per-repository choice that writes no files into the project itself. You can also save to project or global scope.
|
|
122
|
+
|
|
123
|
+
## Profiles as situations
|
|
124
|
+
|
|
125
|
+
A profile *is* a situation. "Reviewing a PR," "scouting an unfamiliar repo," "heads-down implementation" are each just a profile with a curated set of resources and (optionally) a model. Switching the whole situation is one action:
|
|
126
|
+
|
|
127
|
+
```bash
|
|
128
|
+
/profiles review # swap to the review situation
|
|
129
|
+
```
|
|
130
|
+
|
|
131
|
+
## Per-agent profiles
|
|
132
|
+
|
|
133
|
+
When you delegate to a subagent (via the `subagent` extension), the agent can declare which profile it runs under in its frontmatter, so a scout runs read-only on a cheap model while a worker gets the full toolset:
|
|
134
|
+
|
|
135
|
+
```markdown
|
|
136
|
+
---
|
|
137
|
+
name: scout
|
|
138
|
+
description: Fast codebase recon.
|
|
139
|
+
profile: recon
|
|
140
|
+
---
|
|
141
|
+
```
|
|
142
|
+
|
|
143
|
+
Agents are discovered from your catalog's `agents/` directory the same way other kinds are, so the whole set travels with the catalog.
|
|
144
|
+
|
|
145
|
+
## Install at user level
|
|
146
|
+
|
|
147
|
+
Live scanning covers the day-to-day. For portability — a machine without the catalog checkout, or offline use — copy a trusted directory's resources into your user config:
|
|
148
|
+
|
|
149
|
+
```bash
|
|
150
|
+
/install-resources <dir> # copy, skipping files that already exist
|
|
151
|
+
/install-resources <dir> --force # overwrite existing files
|
|
152
|
+
```
|
|
153
|
+
|
|
154
|
+
This copies `skills`, `extensions`, `prompts`, `themes`, `profiles`, and `agents` from `<dir>` into `~/.pi/agent/…`. The source must be trusted first (Pi prompts if it isn't, since extension code is executable). Installed agents land in `~/.pi/agent/agents`, where subagent discovery reads them.
|
|
155
|
+
|
|
156
|
+
## Backup and restore
|
|
157
|
+
|
|
158
|
+
Back up your personal configuration — profile definitions and resource settings — to a single JSON file:
|
|
159
|
+
|
|
160
|
+
```bash
|
|
161
|
+
/config-backup # writes a default-named backup
|
|
162
|
+
/config-backup my.json # writes to a path
|
|
163
|
+
/config-restore my.json # merges it back, after confirmation
|
|
164
|
+
```
|
|
165
|
+
|
|
166
|
+
The backup bundles your profiles and the resource settings (`resourceProfiles`, `activeResourceProfile`, `externalResourceRoots`, `trustedResourceRoots`). It does **not** copy the catalog itself — that is what your git repository is for.
|
|
167
|
+
|
|
168
|
+
> **Security:** restore is deliberately cautious. Restored external roots come back **untrusted**, so a new machine re-prompts before any code loads, and restore confirms before overwriting existing local config.
|
|
169
|
+
|
|
170
|
+
## Precedence
|
|
171
|
+
|
|
172
|
+
When the same resource name exists in more than one place, the order is:
|
|
173
|
+
|
|
174
|
+
```
|
|
175
|
+
Project (.pi/) > User (~/.pi/agent/) > External roots (in registration order) > Bundled
|
|
176
|
+
```
|
|
177
|
+
|
|
178
|
+
Same-named items shadow lower-precedence ones, and Manage Library shows each item's source so you can see which copy is winning.
|
|
@@ -0,0 +1,68 @@
|
|
|
1
|
+
# Self-Adaptation
|
|
2
|
+
|
|
3
|
+
Pi can turn something you just did into a durable, reusable capability. When a session reveals a repeatable workflow, Pi can draft a new **skill** or **extension** for it, check it for overlap with what you already have, validate it, and — once you approve — make it live the same turn. No restart, no hand-authoring boilerplate.
|
|
4
|
+
|
|
5
|
+
This keeps a human on the edge of the loop: Pi proposes, you confirm, then it activates.
|
|
6
|
+
|
|
7
|
+
## Table of Contents
|
|
8
|
+
|
|
9
|
+
- [Commands](#commands)
|
|
10
|
+
- [How proposal and activation are separated](#how-proposal-and-activation-are-separated)
|
|
11
|
+
- [Skillify](#skillify)
|
|
12
|
+
- [Extensionify](#extensionify)
|
|
13
|
+
- [Learn](#learn)
|
|
14
|
+
- [Duplicate detection](#duplicate-detection)
|
|
15
|
+
- [Going live](#going-live)
|
|
16
|
+
|
|
17
|
+
## Commands
|
|
18
|
+
|
|
19
|
+
| Command | Purpose |
|
|
20
|
+
|---------|---------|
|
|
21
|
+
| `/skillify` | Capture a repeatable workflow from the session and draft a new skill. |
|
|
22
|
+
| `/extensionify` | Scaffold a new extension (a tool or command) from the session. |
|
|
23
|
+
| `/learn` | Reflect on the session, classify the lesson, and route it to the right outcome. |
|
|
24
|
+
|
|
25
|
+
The same analysis is also available to the model as the `skillify`, `extensionify`, and `skill_audit` tools.
|
|
26
|
+
|
|
27
|
+
## How proposal and activation are separated
|
|
28
|
+
|
|
29
|
+
Authoring has a hard boundary between *drafting* and *committing*:
|
|
30
|
+
|
|
31
|
+
- **Proposal** is non-destructive. The `skillify` and `extensionify` tools analyze the session, generate a draft, validate it, and return it. They never write to disk and never reload anything, so they are safe for the model — or a subagent — to call.
|
|
32
|
+
- **Activation** is human-gated. The persistent write and the live reload happen only at the `/skillify` and `/extensionify` commands in your main session, and only after you confirm the draft.
|
|
33
|
+
|
|
34
|
+
Because activation lives only at the interactive layer, a subagent can at most produce a proposal — it can never persist or activate a capability on its own.
|
|
35
|
+
|
|
36
|
+
## Skillify
|
|
37
|
+
|
|
38
|
+
`/skillify` builds a [skill](skills.md) from what the session demonstrated:
|
|
39
|
+
|
|
40
|
+
1. It captures the repeatable process — goal, inputs, outputs, success criteria, and any corrections you made along the way.
|
|
41
|
+
2. It applies skill-authoring doctrine (a focused, one-job skill with clear frontmatter).
|
|
42
|
+
3. It drafts the `SKILL.md` and validates the name and description.
|
|
43
|
+
4. It runs [duplicate detection](#duplicate-detection) against your loaded skills.
|
|
44
|
+
5. It shows you the draft. On your confirmation, it writes the skill to `~/.pi/agent/skills/<name>/` and reloads it so `/skill:<name>` works immediately.
|
|
45
|
+
|
|
46
|
+
The doctrine skills it leans on (`skill-architect`, `pi-harness-learning`) ship with Pi as bundled skills, so skillify works out of the box. Like any bundled resource, they can be overridden by your own versions or filtered out with a [resource profile](resources.md).
|
|
47
|
+
|
|
48
|
+
## Extensionify
|
|
49
|
+
|
|
50
|
+
`/extensionify` scaffolds an [extension](extensions.md) — an `index.ts` factory that registers a tool or command, plus an optional `package.json` manifest.
|
|
51
|
+
|
|
52
|
+
Before anything is offered for activation, the candidate is **smoke-tested in isolation**: Pi runs the generated factory against a throwaway runtime, never the live one. If it throws, times out, or fails validation, the proposal comes back rejected with diagnostics, and activation refuses to write or load it. Only a clean isolated load — and your explicit confirmation — lets the real extension be written to `~/.pi/agent/extensions/<name>/` and loaded live.
|
|
53
|
+
|
|
54
|
+
## Learn
|
|
55
|
+
|
|
56
|
+
`/learn` is the broader post-session pass. It summarizes the durable lesson and classifies it: is this a memory, a refinement to an existing skill, a brand-new skill, a prompt, an extension, or nothing worth keeping? It then routes the lesson to the matching proposal — `skillify` or `extensionify`, a targeted edit, or a note — and surfaces the result for you to activate.
|
|
57
|
+
|
|
58
|
+
`/learn` orchestrates; it never writes or activates on its own. Long-term memory storage is handled outside Pi; `/learn` routes to it rather than implementing it.
|
|
59
|
+
|
|
60
|
+
## Duplicate detection
|
|
61
|
+
|
|
62
|
+
The `skill_audit` tool guards against accumulating near-identical skills. Given a draft's name, description, and body, it scans your loaded skills and scores keyword overlap. Matches above the similarity threshold are flagged so you can **merge or refine** an existing skill instead of adding a redundant one.
|
|
63
|
+
|
|
64
|
+
It runs entirely locally — no network call, no embedding model — so it is safe and instant. You can also call it on its own to audit an existing set of skills for overlap.
|
|
65
|
+
|
|
66
|
+
## Going live
|
|
67
|
+
|
|
68
|
+
Activation finishes by hot-reloading the new capability through the same live load/unload path the [Resources hub](resources.md#manage-library) uses. A skill or extension you just approved is usable the moment it is written — the ingest → author → live loop closes in a single turn.
|
|
@@ -1,12 +1,12 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "pi-extension-custom-provider",
|
|
3
|
-
"version": "0.80.
|
|
3
|
+
"version": "0.80.50",
|
|
4
4
|
"lockfileVersion": 3,
|
|
5
5
|
"requires": true,
|
|
6
6
|
"packages": {
|
|
7
7
|
"": {
|
|
8
8
|
"name": "pi-extension-custom-provider",
|
|
9
|
-
"version": "0.80.
|
|
9
|
+
"version": "0.80.50",
|
|
10
10
|
"dependencies": {
|
|
11
11
|
"@anthropic-ai/sdk": "^0.52.0"
|
|
12
12
|
}
|
|
@@ -1,12 +1,12 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "pi-extension-sandbox",
|
|
3
|
-
"version": "0.80.
|
|
3
|
+
"version": "0.80.50",
|
|
4
4
|
"lockfileVersion": 3,
|
|
5
5
|
"requires": true,
|
|
6
6
|
"packages": {
|
|
7
7
|
"": {
|
|
8
8
|
"name": "pi-extension-sandbox",
|
|
9
|
-
"version": "0.80.
|
|
9
|
+
"version": "0.80.50",
|
|
10
10
|
"dependencies": {
|
|
11
11
|
"@anthropic-ai/sandbox-runtime": "^0.0.26"
|
|
12
12
|
}
|
|
@@ -1,12 +1,12 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "pi-extension-with-deps",
|
|
3
|
-
"version": "0.80.
|
|
3
|
+
"version": "0.80.50",
|
|
4
4
|
"lockfileVersion": 3,
|
|
5
5
|
"requires": true,
|
|
6
6
|
"packages": {
|
|
7
7
|
"": {
|
|
8
8
|
"name": "pi-extension-with-deps",
|
|
9
|
-
"version": "0.80.
|
|
9
|
+
"version": "0.80.50",
|
|
10
10
|
"dependencies": {
|
|
11
11
|
"ms": "^2.1.3"
|
|
12
12
|
},
|
package/npm-shrinkwrap.json
CHANGED
|
@@ -1,17 +1,17 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@caupulican/pi-adaptative",
|
|
3
|
-
"version": "0.80.
|
|
3
|
+
"version": "0.80.53",
|
|
4
4
|
"lockfileVersion": 3,
|
|
5
5
|
"requires": true,
|
|
6
6
|
"packages": {
|
|
7
7
|
"": {
|
|
8
8
|
"name": "@caupulican/pi-adaptative",
|
|
9
|
-
"version": "0.80.
|
|
9
|
+
"version": "0.80.53",
|
|
10
10
|
"license": "MIT",
|
|
11
11
|
"dependencies": {
|
|
12
|
-
"@caupulican/pi-agent-core": "^0.80.
|
|
13
|
-
"@caupulican/pi-ai": "^0.80.
|
|
14
|
-
"@caupulican/pi-tui": "^0.80.
|
|
12
|
+
"@caupulican/pi-agent-core": "^0.80.53",
|
|
13
|
+
"@caupulican/pi-ai": "^0.80.53",
|
|
14
|
+
"@caupulican/pi-tui": "^0.80.53",
|
|
15
15
|
"@silvia-odwyer/photon-node": "0.3.4",
|
|
16
16
|
"chalk": "5.6.2",
|
|
17
17
|
"cross-spawn": "7.0.6",
|
|
@@ -474,11 +474,11 @@
|
|
|
474
474
|
}
|
|
475
475
|
},
|
|
476
476
|
"node_modules/@caupulican/pi-agent-core": {
|
|
477
|
-
"version": "0.80.
|
|
478
|
-
"resolved": "https://registry.npmjs.org/@caupulican/pi-agent-core/-/pi-agent-core-0.80.
|
|
477
|
+
"version": "0.80.53",
|
|
478
|
+
"resolved": "https://registry.npmjs.org/@caupulican/pi-agent-core/-/pi-agent-core-0.80.53.tgz",
|
|
479
479
|
"license": "MIT",
|
|
480
480
|
"dependencies": {
|
|
481
|
-
"@caupulican/pi-ai": "^0.80.
|
|
481
|
+
"@caupulican/pi-ai": "^0.80.53",
|
|
482
482
|
"ignore": "7.0.5",
|
|
483
483
|
"typebox": "1.1.38",
|
|
484
484
|
"yaml": "2.9.0"
|
|
@@ -488,8 +488,8 @@
|
|
|
488
488
|
}
|
|
489
489
|
},
|
|
490
490
|
"node_modules/@caupulican/pi-ai": {
|
|
491
|
-
"version": "0.80.
|
|
492
|
-
"resolved": "https://registry.npmjs.org/@caupulican/pi-ai/-/pi-ai-0.80.
|
|
491
|
+
"version": "0.80.53",
|
|
492
|
+
"resolved": "https://registry.npmjs.org/@caupulican/pi-ai/-/pi-ai-0.80.53.tgz",
|
|
493
493
|
"license": "MIT",
|
|
494
494
|
"dependencies": {
|
|
495
495
|
"@anthropic-ai/sdk": "0.91.1",
|
|
@@ -511,8 +511,8 @@
|
|
|
511
511
|
}
|
|
512
512
|
},
|
|
513
513
|
"node_modules/@caupulican/pi-tui": {
|
|
514
|
-
"version": "0.80.
|
|
515
|
-
"resolved": "https://registry.npmjs.org/@caupulican/pi-tui/-/pi-tui-0.80.
|
|
514
|
+
"version": "0.80.53",
|
|
515
|
+
"resolved": "https://registry.npmjs.org/@caupulican/pi-tui/-/pi-tui-0.80.53.tgz",
|
|
516
516
|
"license": "MIT",
|
|
517
517
|
"dependencies": {
|
|
518
518
|
"get-east-asian-width": "1.6.0",
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@caupulican/pi-adaptative",
|
|
3
|
-
"version": "0.80.
|
|
3
|
+
"version": "0.80.53",
|
|
4
4
|
"description": "Adaptive fork of Pi coding agent for self-evolving agent harness experiments",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"piConfig": {
|
|
@@ -41,9 +41,9 @@
|
|
|
41
41
|
"prepublishOnly": "npm run clean && npm run build && npm run shrinkwrap"
|
|
42
42
|
},
|
|
43
43
|
"dependencies": {
|
|
44
|
-
"@caupulican/pi-agent-core": "^0.80.
|
|
45
|
-
"@caupulican/pi-ai": "^0.80.
|
|
46
|
-
"@caupulican/pi-tui": "^0.80.
|
|
44
|
+
"@caupulican/pi-agent-core": "^0.80.53",
|
|
45
|
+
"@caupulican/pi-ai": "^0.80.53",
|
|
46
|
+
"@caupulican/pi-tui": "^0.80.53",
|
|
47
47
|
"@silvia-odwyer/photon-node": "0.3.4",
|
|
48
48
|
"chalk": "5.6.2",
|
|
49
49
|
"cross-spawn": "7.0.6",
|