agent-policy-kit 0.3.0 → 0.4.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/AGENT_INSTALL.md +126 -42
- package/CHANGELOG.md +52 -3
- package/README.md +17 -10
- package/docs/README.md +46 -0
- package/docs/design/2026-11-01-documentation-structure.md +58 -0
- package/docs/guide/commands.md +375 -0
- package/docs/guide/configurator.md +163 -0
- package/docs/guide/getting-started.md +119 -0
- package/docs/guide/preferences.md +168 -0
- package/docs/guide/privacy.md +76 -0
- package/docs/guide/updates-and-removal.md +188 -0
- package/docs/maintainers/architecture.md +71 -0
- package/docs/maintainers/development.md +93 -0
- package/docs/maintainers/model-review.md +101 -0
- package/docs/maintainers/release.md +114 -0
- package/docs/maintainers/verification.md +95 -0
- package/docs/maintainers/website.md +112 -0
- package/docs/reference/assistants.md +165 -0
- package/docs/reference/model-catalog.md +194 -0
- package/docs/reference/ownership.md +177 -0
- package/docs/reference/presets.md +128 -0
- package/docs/reference/roles.md +157 -0
- package/docs/research/2026-11-01-model-review.md +341 -0
- package/docs/research/limits-evidence.md +28 -0
- package/models/README.md +2 -6
- package/models/catalog.json +51 -20
- package/package.json +2 -2
- package/policies/balanced.json +1 -1
- package/policies/fast.json +1 -11
- package/policies/quality.json +2 -12
- package/site/index.html +28 -19
- package/src/inspect.mjs +2 -1
- package/src/install.mjs +14 -8
- package/src/release.mjs +1 -1
- package/src/share.mjs +4 -4
- package/docs/architecture.md +0 -17
- package/docs/compatibility.md +0 -39
- package/docs/configuration-page.md +0 -44
- package/docs/deployment.md +0 -33
- package/docs/development.md +0 -31
- package/docs/installation.md +0 -23
- package/docs/limits-evidence.md +0 -24
- package/docs/model-catalog.md +0 -102
- package/docs/model-updates.md +0 -22
- package/docs/npm-release.md +0 -27
- package/docs/policy.md +0 -16
- package/docs/privacy.md +0 -9
- package/docs/recovery.md +0 -13
- package/docs/releases.md +0 -40
- package/docs/use-cases.md +0 -25
- package/docs/verification.md +0 -61
|
@@ -0,0 +1,168 @@
|
|
|
1
|
+
# Preferences
|
|
2
|
+
|
|
3
|
+
This document describes the preferences JSON format and its validation rules. It also shows how to create, check and apply a preferences file. It is for advanced users who want to keep their APK choices in a file instead of in a configurator command.
|
|
4
|
+
|
|
5
|
+
## What preferences are
|
|
6
|
+
|
|
7
|
+
*Preferences* are JSON data that select the roles and, for each assistant, the models, effort levels, parallel limit and models to avoid. APK reads preferences, checks them, and writes native files from them. Preferences contain data only, never commands or credentials.
|
|
8
|
+
|
|
9
|
+
APK checks preferences in two ways:
|
|
10
|
+
|
|
11
|
+
- The [JSON Schema](../../schema/policy.schema.json) describes the shape.
|
|
12
|
+
- The validator in APK also checks the models and effort levels against the model catalog of the release.
|
|
13
|
+
|
|
14
|
+
Preferences apply only when the main agent decides to delegate. They do not turn on a subagent feature.
|
|
15
|
+
|
|
16
|
+
## Create a preferences file
|
|
17
|
+
|
|
18
|
+
1. Create a file with the Standard preset of the release:
|
|
19
|
+
|
|
20
|
+
```sh
|
|
21
|
+
npx --yes --ignore-scripts --package agent-policy-kit@0.4.0 agent-policy init --policy ./preferences.json
|
|
22
|
+
```
|
|
23
|
+
|
|
24
|
+
2. Edit the file. Use the rules below.
|
|
25
|
+
|
|
26
|
+
`init` never replaces an existing file. The other presets of the release are in the `policies/` folder of the package: `fast.json` (Light), `balanced.json` (Standard) and `quality.json` (Top-tier).
|
|
27
|
+
|
|
28
|
+
## Format
|
|
29
|
+
|
|
30
|
+
### Top level
|
|
31
|
+
|
|
32
|
+
| Field | Required | Value |
|
|
33
|
+
|---|---|---|
|
|
34
|
+
| `schemaVersion` | Yes | `1` |
|
|
35
|
+
| `maxConcurrent` | Yes | A whole number from 1 to 32. The shared parallel limit. |
|
|
36
|
+
| `clients` | Yes | An object with at least one assistant. |
|
|
37
|
+
| `selectedRoles` | No | A list of role IDs. If you omit it, APK configures all six roles of the release. |
|
|
38
|
+
|
|
39
|
+
No other field is allowed.
|
|
40
|
+
|
|
41
|
+
### Assistants
|
|
42
|
+
|
|
43
|
+
The keys of `clients` are `chatgpt` (Codex), `claude` (Claude Code), `kimi` (Kimi Code), `gemini` (Antigravity) and `grok` (Grok Build). An assistant that is not in `clients` is not configured. The keys `codex` and `agy` from version 0.2.0 and earlier are not accepted.
|
|
44
|
+
|
|
45
|
+
Each assistant has these fields:
|
|
46
|
+
|
|
47
|
+
| Field | Required | Value |
|
|
48
|
+
|---|---|---|
|
|
49
|
+
| `code` | Yes | A choice. The default for the Coder, Reviewer and Test writer roles. |
|
|
50
|
+
| `light` | Yes | A choice. The default for the Code explorer, Docs writer and Task runner roles. |
|
|
51
|
+
| `roles` | No | An object with a choice for one or more role IDs. It replaces `code` or `light` for that role. |
|
|
52
|
+
| `avoidModels` | Yes | A list of model IDs, at most 32, without duplicates. It can be empty. |
|
|
53
|
+
| `maxConcurrent` | No | A whole number from 1 to 32. It replaces the shared `maxConcurrent` for this assistant. |
|
|
54
|
+
|
|
55
|
+
The [roles reference](../reference/roles.md) describes each role and its ID.
|
|
56
|
+
|
|
57
|
+
### Choices
|
|
58
|
+
|
|
59
|
+
A *choice* is an object with exactly two fields:
|
|
60
|
+
|
|
61
|
+
| Field | Value |
|
|
62
|
+
|---|---|
|
|
63
|
+
| `model` | A model ID. 1 to 128 characters: letters, digits and `. _ : @ / [ ] -`. It starts with a letter or digit. |
|
|
64
|
+
| `effort` | An effort level, or `null`. `null` sets no explicit effort, so the assistant uses its native default. |
|
|
65
|
+
|
|
66
|
+
### Example
|
|
67
|
+
|
|
68
|
+
```json
|
|
69
|
+
{
|
|
70
|
+
"schemaVersion": 1,
|
|
71
|
+
"maxConcurrent": 3,
|
|
72
|
+
"selectedRoles": ["worker", "reviewer", "explorer"],
|
|
73
|
+
"clients": {
|
|
74
|
+
"claude": {
|
|
75
|
+
"code": {"model": "claude-sonnet-5-5", "effort": "medium"},
|
|
76
|
+
"light": {"model": "claude-haiku-5-5", "effort": "low"},
|
|
77
|
+
"roles": {
|
|
78
|
+
"reviewer": {"model": "claude-sonnet-5-5", "effort": "high"}
|
|
79
|
+
},
|
|
80
|
+
"avoidModels": ["claude-fable-5-1"]
|
|
81
|
+
},
|
|
82
|
+
"gemini": {
|
|
83
|
+
"maxConcurrent": 2,
|
|
84
|
+
"code": {"model": "pro", "effort": null},
|
|
85
|
+
"light": {"model": "flash", "effort": null},
|
|
86
|
+
"avoidModels": []
|
|
87
|
+
}
|
|
88
|
+
}
|
|
89
|
+
}
|
|
90
|
+
```
|
|
91
|
+
|
|
92
|
+
This example configures three roles in Claude Code and Antigravity. The Claude Reviewer uses high effort. The other Claude code roles use the `code` choice. Antigravity runs at most two subagents at once, as guidance.
|
|
93
|
+
|
|
94
|
+
## Validation rules
|
|
95
|
+
|
|
96
|
+
APK refuses preferences that break one of these rules:
|
|
97
|
+
|
|
98
|
+
- `selectedRoles`, if present, is not empty, has no duplicates and contains only `worker`, `reviewer`, `explorer`, `tester`, `writer` and `routine`.
|
|
99
|
+
- The effort is `null` or a native level of the assistant. Gemini and Grok accept only `null`. The [model catalog reference](../reference/model-catalog.md) lists the levels of each assistant.
|
|
100
|
+
- If the model is in the release catalog, the effort is a level of that model. A model that is not in the catalog can use any native level of the assistant. The assistant must still support it.
|
|
101
|
+
- A Gemini model is a native tier: `pro`, `flash`, `flash_lite` or `inherit`.
|
|
102
|
+
- A Kimi model is not `primary`.
|
|
103
|
+
- For Kimi, selected roles that use the same alias do not request different explicit efforts. [Roles](../reference/roles.md#how-effort-applies) gives the full Kimi effort rules.
|
|
104
|
+
- No selected role uses a model from `avoidModels` of the same assistant.
|
|
105
|
+
|
|
106
|
+
`avoidModels` is routing guidance in the APK instructions. It does not block a model in the assistant.
|
|
107
|
+
|
|
108
|
+
Some conditions can only be checked against the native files, for example missing Kimi aliases. APK reports them as prerequisites when you run setup. The [assistants reference](../reference/assistants.md) lists them.
|
|
109
|
+
|
|
110
|
+
## Check a preferences file
|
|
111
|
+
|
|
112
|
+
APK has no separate validation command. A preview checks the file and writes nothing:
|
|
113
|
+
|
|
114
|
+
```sh
|
|
115
|
+
npx --yes --ignore-scripts --package agent-policy-kit@0.4.0 agent-policy setup --policy ./preferences.json
|
|
116
|
+
```
|
|
117
|
+
|
|
118
|
+
If the file is not valid, the command fails with `INVALID_POLICY`. The file must be a regular file of at most 64 KiB, not a symbolic link.
|
|
119
|
+
|
|
120
|
+
## Apply a preferences file
|
|
121
|
+
|
|
122
|
+
Use one of these methods.
|
|
123
|
+
|
|
124
|
+
### First setup, or the same values again
|
|
125
|
+
|
|
126
|
+
1. Preview the setup:
|
|
127
|
+
|
|
128
|
+
```sh
|
|
129
|
+
npx --yes --ignore-scripts --package agent-policy-kit@0.4.0 agent-policy setup --policy ./preferences.json
|
|
130
|
+
```
|
|
131
|
+
|
|
132
|
+
2. Apply it:
|
|
133
|
+
|
|
134
|
+
```sh
|
|
135
|
+
npx --yes --ignore-scripts --package agent-policy-kit@0.4.0 agent-policy setup --policy ./preferences.json --apply
|
|
136
|
+
```
|
|
137
|
+
|
|
138
|
+
`--policy` is conservative. If APK already has a setup with other values, it stops with `INSTALLATION_CONFLICT` or `POLICY_CONFLICT`.
|
|
139
|
+
|
|
140
|
+
### Replace an earlier setup
|
|
141
|
+
|
|
142
|
+
To replace saved values with the values of a file, send the file as `--config`:
|
|
143
|
+
|
|
144
|
+
1. Encode the file as base64url:
|
|
145
|
+
|
|
146
|
+
```sh
|
|
147
|
+
node -e 'process.stdout.write(Buffer.from(JSON.stringify(JSON.parse(require("fs").readFileSync(process.argv[1],"utf8")))).toString("base64url"))' ./preferences.json
|
|
148
|
+
```
|
|
149
|
+
|
|
150
|
+
2. Preview the setup with the encoded value:
|
|
151
|
+
|
|
152
|
+
```sh
|
|
153
|
+
npx --yes --ignore-scripts --package agent-policy-kit@0.4.0 agent-policy setup --config ENCODED_VALUE
|
|
154
|
+
```
|
|
155
|
+
|
|
156
|
+
3. Run the same command with `--apply`.
|
|
157
|
+
|
|
158
|
+
The decoded JSON can be at most 64 KiB. For all input modes, see [Commands](commands.md#input-modes).
|
|
159
|
+
|
|
160
|
+
## Saved preferences
|
|
161
|
+
|
|
162
|
+
After a setup with `--apply`, APK saves the latest requested preferences as `policy.json` in the state directory. A setup without an input mode uses this file. This file is a request, not proof of what each assistant has. If one assistant failed, its receipt still records its earlier values. The [ownership reference](../reference/ownership.md) explains receipts and the state directory.
|
|
163
|
+
|
|
164
|
+
## Related documents
|
|
165
|
+
|
|
166
|
+
- [Commands](commands.md): all input modes and options.
|
|
167
|
+
- [Presets reference](../reference/presets.md): the values of the release presets.
|
|
168
|
+
- [Model catalog reference](../reference/model-catalog.md): known models and effort levels.
|
|
@@ -0,0 +1,76 @@
|
|
|
1
|
+
# Privacy
|
|
2
|
+
|
|
3
|
+
This document lists what APK reads, what it writes and what it never sends, for the CLI and for the configurator page. It is for everyone who uses APK or wants to check it before use.
|
|
4
|
+
|
|
5
|
+
## Summary
|
|
6
|
+
|
|
7
|
+
- APK runs on your computer, writes native settings and exits.
|
|
8
|
+
- APK sends no data to a server. It has no telemetry, no proxy and no background process.
|
|
9
|
+
- APK does not read your conversations, and it does not sign in or call a model.
|
|
10
|
+
- The APK state directory can contain secrets from your existing settings. Keep it private.
|
|
11
|
+
|
|
12
|
+
## What the CLI reads
|
|
13
|
+
|
|
14
|
+
| Source | When | Why |
|
|
15
|
+
|---|---|---|
|
|
16
|
+
| Preferences: a preset of the release, the saved `policy.json`, a `--policy` file or a `--config` value | `setup`, `install` | To know what to configure. |
|
|
17
|
+
| Native configuration of each assistant: its settings file, role files and instructions file | `setup`, `install`, `show`, `doctor`, `uninstall` | To plan changes, to show current settings and to verify ownership. |
|
|
18
|
+
| The APK state directory: receipts, saved preferences, journal and backups | `setup`, `install`, `show`, `doctor`, `uninstall` | To know what APK owns. |
|
|
19
|
+
| Assistant executables | `setup`, `install`, `detect`, `doctor` | To find installed assistants. |
|
|
20
|
+
| Environment variables, for example `PATH`, the native-home variables and the Claude subagent variables | All commands that read assistants | To find executables and the active native folders. |
|
|
21
|
+
|
|
22
|
+
To find an assistant, APK starts each candidate executable with `--version`. For Kimi and Antigravity, it can also use `--help`. These probes have a time limit and an output limit. APK does not start a session or send a task.
|
|
23
|
+
|
|
24
|
+
APK does not read transcripts, session history, prompts or project files. The [assistants reference](../reference/assistants.md) lists the files that APK reads and writes for each assistant.
|
|
25
|
+
|
|
26
|
+
## What the CLI writes
|
|
27
|
+
|
|
28
|
+
The CLI writes only with `--apply`, or with `init`:
|
|
29
|
+
|
|
30
|
+
- The native settings, role files and instruction block that APK owns, in the user folders of each assistant.
|
|
31
|
+
- Private files in the state directory: receipts, saved preferences, a lock, a journal and transaction backups. Folders are readable only by you, and files are readable and writable only by you.
|
|
32
|
+
- `init` creates one new preferences file.
|
|
33
|
+
|
|
34
|
+
With `--config`, APK writes the decoded preferences to a private temporary file. It removes that file when the command ends.
|
|
35
|
+
|
|
36
|
+
APK does not provision, copy or transfer credentials. It does not change your main model, sign-in, permissions or unrelated settings.
|
|
37
|
+
|
|
38
|
+
## What the CLI prints
|
|
39
|
+
|
|
40
|
+
- Paths appear as `~/...` or `<state-dir>/...`, not as full private paths.
|
|
41
|
+
- Errors appear as codes, not as raw error text.
|
|
42
|
+
- The output does not contain configuration bodies or raw executable output.
|
|
43
|
+
- `show` does not print prompts or credentials. It refuses values that look like tokens or private paths and marks the read as incomplete.
|
|
44
|
+
|
|
45
|
+
## The state directory
|
|
46
|
+
|
|
47
|
+
The state directory contains copies of earlier versions of your native files. These copies can contain secrets that were already in your settings.
|
|
48
|
+
|
|
49
|
+
- Keep the state directory private.
|
|
50
|
+
- Never publish receipts, backups or backup indexes.
|
|
51
|
+
- Do not share the content of the state directory to report a problem. Share the error codes instead.
|
|
52
|
+
|
|
53
|
+
The [ownership reference](../reference/ownership.md#state-directory) tells where the state directory is and what it contains.
|
|
54
|
+
|
|
55
|
+
## The configurator page
|
|
56
|
+
|
|
57
|
+
- The page is one static HTML file. It has no backend.
|
|
58
|
+
- It makes no requests while you use it and has no telemetry. Its fonts and data are inside the file.
|
|
59
|
+
- Your choices stay in the browser. A share link stores them in the part of the address after `#`. Browsers do not send this part to the server.
|
|
60
|
+
- Links to other sites load only when you click them.
|
|
61
|
+
- The page never runs the command and has no access to your accounts or files.
|
|
62
|
+
|
|
63
|
+
Your browser loads the hosted page like any other web page.
|
|
64
|
+
|
|
65
|
+
## What other software does
|
|
66
|
+
|
|
67
|
+
APK does not change how other software handles your data:
|
|
68
|
+
|
|
69
|
+
- `npx` downloads the APK package from the npm registry.
|
|
70
|
+
- Each assistant keeps its own provider and account behavior. When it runs a subagent, it uses its own connection to its provider.
|
|
71
|
+
|
|
72
|
+
## Related documents
|
|
73
|
+
|
|
74
|
+
- [Getting started](getting-started.md): the first setup.
|
|
75
|
+
- [Commands](commands.md): what each command reads and writes.
|
|
76
|
+
- [Ownership reference](../reference/ownership.md): receipts, state and backups.
|
|
@@ -0,0 +1,188 @@
|
|
|
1
|
+
# Updates and removal
|
|
2
|
+
|
|
3
|
+
This document shows how to choose a configuration release, upgrade or downgrade to it, remove APK and recover from an interrupted change. It also lists what a release does not freeze. It is for people who already use APK and want to change or remove their setup.
|
|
4
|
+
|
|
5
|
+
## Configuration releases
|
|
6
|
+
|
|
7
|
+
A *configuration release* is one version of the APK npm package. Each version freezes these parts:
|
|
8
|
+
|
|
9
|
+
- The named presets: Light, Standard and Top-tier.
|
|
10
|
+
- The model catalog with its effort levels.
|
|
11
|
+
- The native role templates and the delegation instructions.
|
|
12
|
+
- The release notes and the configurator page.
|
|
13
|
+
|
|
14
|
+
There is no separate preset version. The package version is the release version. Published versions are not changed later.
|
|
15
|
+
|
|
16
|
+
Installing or updating the npm package does not change your native files. Only `setup` or `uninstall` with `--apply` changes them.
|
|
17
|
+
|
|
18
|
+
## Choose a release
|
|
19
|
+
|
|
20
|
+
1. Read the [release notes](../../CHANGELOG.md). Each entry says why the release exists, who should update and how to migrate or roll back.
|
|
21
|
+
2. Show the release and its notes with the `release` command:
|
|
22
|
+
|
|
23
|
+
```sh
|
|
24
|
+
npx --yes --ignore-scripts --package agent-policy-kit@0.4.0 agent-policy release
|
|
25
|
+
```
|
|
26
|
+
|
|
27
|
+
3. Check the installed versions of your assistants and the models that your account can use.
|
|
28
|
+
|
|
29
|
+
A newer release or model is not always better for your work, your account or your limits. APK never changes your models without a setup command.
|
|
30
|
+
|
|
31
|
+
A release that is not published yet has the heading `VERSION — Unreleased` in the release notes. Its `npx` command does not work until npm serves the version. To list the published versions, run `npm view agent-policy-kit versions`. The [website document](../maintainers/website.md#release-status-on-the-page) tells what the configurator page shows for a release that is not published.
|
|
32
|
+
|
|
33
|
+
## Upgrade or downgrade
|
|
34
|
+
|
|
35
|
+
### To the defaults of a release
|
|
36
|
+
|
|
37
|
+
1. Preview the setup with the release that you want:
|
|
38
|
+
|
|
39
|
+
```sh
|
|
40
|
+
npx --yes --ignore-scripts --package agent-policy-kit@0.4.0 agent-policy setup --release
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
2. To select another preset, add `--preset fast` (Light) or `--preset quality` (Top-tier). The default is `balanced` (Standard).
|
|
44
|
+
3. Read the preview.
|
|
45
|
+
4. Run the same command with `--apply`.
|
|
46
|
+
|
|
47
|
+
To downgrade, use the same steps with an older version in `--package agent-policy-kit@VERSION`. Before you downgrade, read [Migration boundaries](#migration-boundaries). Some changes need a removal first.
|
|
48
|
+
|
|
49
|
+
### To your own choices
|
|
50
|
+
|
|
51
|
+
1. Open the configurator page of the release, for example <https://agent-policy-kit.trymenow.io/v/0.4.0/>.
|
|
52
|
+
2. Make your choices and copy the command. The command is pinned to the release of the page.
|
|
53
|
+
3. Preview and apply it as described in [Getting started](getting-started.md#set-up-with-the-configurator).
|
|
54
|
+
|
|
55
|
+
You can also apply a preferences file with `--config`. See [Preferences](preferences.md#replace-an-earlier-setup).
|
|
56
|
+
|
|
57
|
+
### What happens during an update
|
|
58
|
+
|
|
59
|
+
Explicit tool arguments, `--release`, `--preset` and `--config` can replace an earlier APK setup in one step. There is no removal before the new setup.
|
|
60
|
+
|
|
61
|
+
- APK checks that the files it owns still have the values it wrote.
|
|
62
|
+
- It rebuilds your original values in memory and writes the new release on top of them.
|
|
63
|
+
- If a check fails or a prerequisite is missing, it changes nothing for that assistant. The earlier release stays.
|
|
64
|
+
- If a write fails late, it rolls back to the earlier release.
|
|
65
|
+
- Unrelated changes that you made later stay.
|
|
66
|
+
|
|
67
|
+
Each assistant has its own transaction. One assistant can move to the new release while another keeps its earlier release. Read the result of each assistant. Run `doctor` to see the release that each assistant has now.
|
|
68
|
+
|
|
69
|
+
The [ownership reference](../reference/ownership.md#updates) describes the transaction steps.
|
|
70
|
+
|
|
71
|
+
### Migration boundaries
|
|
72
|
+
|
|
73
|
+
A *migration boundary* is a release change that setup cannot do in place. At a boundary, setup stops for the affected assistant and changes nothing. First remove the APK settings of that assistant with a release that can read its receipt. Then set up with the other release. The release notes record each boundary in the entry of the newer release.
|
|
74
|
+
|
|
75
|
+
These boundaries are known:
|
|
76
|
+
|
|
77
|
+
| Assistant | Change | Setup without removal | Remove with |
|
|
78
|
+
|---|---|---|---|
|
|
79
|
+
| Claude | From 0.4.0 to 0.3.0 or earlier | `INVALID_RECEIPT` | 0.4.0 |
|
|
80
|
+
| ChatGPT and Gemini | From 0.2.0 or earlier to 0.3.0 or later | `OWNERSHIP_CONFLICT` | The release that created the settings, for example 0.2.0 |
|
|
81
|
+
| ChatGPT and Gemini | From 0.3.0 or later to 0.2.0 or earlier | `OWNERSHIP_CONFLICT` | The release that created the settings, for example 0.4.0 |
|
|
82
|
+
|
|
83
|
+
**Claude, 0.4.0 to an older release.** A 0.4.0 Claude receipt owns `CLAUDE_CODE_SUBAGENT_EFFORT` when the effort of the default subagent role is pinned. Every preset pins it. Releases 0.3.0 and earlier do not know this setting, so they refuse the receipt. To move Claude back to 0.3.0:
|
|
84
|
+
|
|
85
|
+
1. Remove the Claude settings with 0.4.0:
|
|
86
|
+
|
|
87
|
+
```sh
|
|
88
|
+
npx --yes --ignore-scripts --package agent-policy-kit@0.4.0 agent-policy uninstall --client claude --apply
|
|
89
|
+
```
|
|
90
|
+
|
|
91
|
+
2. Set up Claude with 0.3.0.
|
|
92
|
+
|
|
93
|
+
ChatGPT, Kimi, Gemini and Grok move from 0.4.0 to 0.3.0 in place.
|
|
94
|
+
|
|
95
|
+
**ChatGPT and Gemini, 0.2.0 and 0.3.0.** Release 0.3.0 renamed the assistant IDs `codex` to `chatgpt` and `agy` to `gemini`. Releases 0.3.0 and later do not read receipts under the old IDs, and releases 0.2.0 and earlier do not know the new IDs. To move from 0.2.0 to a later release:
|
|
96
|
+
|
|
97
|
+
1. Remove the settings with 0.2.0:
|
|
98
|
+
|
|
99
|
+
```sh
|
|
100
|
+
npx --yes --ignore-scripts --package agent-policy-kit@0.2.0 agent-policy uninstall --client codex --apply
|
|
101
|
+
npx --yes --ignore-scripts --package agent-policy-kit@0.2.0 agent-policy uninstall --client agy --apply
|
|
102
|
+
```
|
|
103
|
+
|
|
104
|
+
2. Set up ChatGPT and Gemini with the later release.
|
|
105
|
+
|
|
106
|
+
In the other direction, remove them with `--client chatgpt` and `--client gemini` and the newer release. Claude, Kimi and Grok keep their IDs.
|
|
107
|
+
|
|
108
|
+
Preview each removal without `--apply` first. The [ownership reference](../reference/ownership.md#receipt-formats) explains the receipt formats. The [release notes](../../CHANGELOG.md) of 0.3.0 and 0.4.0 give the details.
|
|
109
|
+
|
|
110
|
+
## What a release does not freeze
|
|
111
|
+
|
|
112
|
+
A release reproduces the declared settings and templates. It does not control the providers:
|
|
113
|
+
|
|
114
|
+
- A model alias can resolve to a newer model. For example, Claude documents that its [model aliases update over time](https://code.claude.com/docs/en/model-config#model-aliases).
|
|
115
|
+
- An old model ID can be retired.
|
|
116
|
+
- Your account access can change.
|
|
117
|
+
|
|
118
|
+
Where reproducibility is important, use a versioned model ID if the assistant supports it. A configured model ID does not prove which model the provider runs.
|
|
119
|
+
|
|
120
|
+
APK has no background updater and requests no live model catalog. Your configured values stay until you run another setup.
|
|
121
|
+
|
|
122
|
+
## Remove APK
|
|
123
|
+
|
|
124
|
+
1. Preview the removal:
|
|
125
|
+
|
|
126
|
+
```sh
|
|
127
|
+
npx --yes --ignore-scripts --package agent-policy-kit@0.4.0 agent-policy uninstall
|
|
128
|
+
```
|
|
129
|
+
|
|
130
|
+
2. Read the preview.
|
|
131
|
+
3. Remove the configuration:
|
|
132
|
+
|
|
133
|
+
```sh
|
|
134
|
+
npx --yes --ignore-scripts --package agent-policy-kit@0.4.0 agent-policy uninstall --apply
|
|
135
|
+
```
|
|
136
|
+
|
|
137
|
+
4. Run `show` to check the current settings.
|
|
138
|
+
|
|
139
|
+
If you used `--home` or `--state-dir` for setup, use the same values here. To remove APK from one assistant only, add `--client ID`.
|
|
140
|
+
|
|
141
|
+
Uninstall uses the receipts in the state directory. It needs no assistant executable and no preferences. It restores the values that you had before the first APK setup, also after release changes. It keeps unrelated later changes. It removes the receipts, but keeps the saved preferences and the private backups in the state directory.
|
|
142
|
+
|
|
143
|
+
You do not need the release that you used for setup. Any release that can read the receipt can remove it. There are two known exceptions:
|
|
144
|
+
|
|
145
|
+
- Releases 0.3.0 and later do not read the ChatGPT and Gemini receipts of 0.2.0 and earlier. Remove these settings with the release that created them.
|
|
146
|
+
- Releases 0.3.0 and earlier cannot read a 0.4.0 Claude receipt that owns `CLAUDE_CODE_SUBAGENT_EFFORT`. Remove these settings with 0.4.0.
|
|
147
|
+
|
|
148
|
+
See [Migration boundaries](#migration-boundaries) and the [ownership reference](../reference/ownership.md#receipt-formats).
|
|
149
|
+
|
|
150
|
+
## Handle local edits
|
|
151
|
+
|
|
152
|
+
APK owns these parts:
|
|
153
|
+
|
|
154
|
+
- The `apk-ROLE` role files that it created.
|
|
155
|
+
- The block between `<!-- BEGIN agent-policy-kit -->` and `<!-- END agent-policy-kit -->` in the instructions file of the assistant.
|
|
156
|
+
- The settings that it set in the native configuration file of the assistant, if the assistant has one.
|
|
157
|
+
|
|
158
|
+
If you change one of these parts, APK calls this *drift*. Update and removal then stop for that assistant with `OWNED_DRIFT`. APK does not overwrite your edit.
|
|
159
|
+
|
|
160
|
+
1. Find your edit in the APK part.
|
|
161
|
+
2. Undo the edit, or move your change outside the APK part.
|
|
162
|
+
3. Run the command again.
|
|
163
|
+
|
|
164
|
+
Do not restore an old backup of the whole file. It can remove other changes that you made later. The [assistants reference](../reference/assistants.md#settings-in-the-configuration-file) lists the owned settings for each assistant. The [ownership reference](../reference/ownership.md#drift) explains how APK detects drift.
|
|
165
|
+
|
|
166
|
+
## Recover from an interrupted change
|
|
167
|
+
|
|
168
|
+
APK stops with one of these codes if an earlier change did not finish:
|
|
169
|
+
|
|
170
|
+
- `INSTALL_LOCKED`: another APK operation holds the lock.
|
|
171
|
+
- `RECOVERY_REQUIRED`: an interrupted transaction left a journal in the state directory.
|
|
172
|
+
|
|
173
|
+
Do not delete the lock or the journal only to make APK continue. Another operation can own it, or the backups can be necessary.
|
|
174
|
+
|
|
175
|
+
1. Make sure that no other APK command runs.
|
|
176
|
+
2. Make a private copy of the affected native files and of the state directory.
|
|
177
|
+
3. Compare the current files with the before and after values that the transaction recorded.
|
|
178
|
+
4. Fix only the changes that APK owns. Keep every unrelated change.
|
|
179
|
+
5. Remove only the markers of the transaction that you fixed.
|
|
180
|
+
6. Run a preview again.
|
|
181
|
+
|
|
182
|
+
The state directory can contain secrets from your existing settings. Never publish configuration files, backups or backup indexes. The [ownership reference](../reference/ownership.md) describes the journal, the lock and the backup files.
|
|
183
|
+
|
|
184
|
+
## Related documents
|
|
185
|
+
|
|
186
|
+
- [Commands](commands.md): all options of `setup`, `release`, `doctor` and `uninstall`.
|
|
187
|
+
- [Release notes](../../CHANGELOG.md): what changed in each release.
|
|
188
|
+
- [Ownership reference](../reference/ownership.md): receipts, state, drift and transactions.
|
|
@@ -0,0 +1,71 @@
|
|
|
1
|
+
# Architecture
|
|
2
|
+
|
|
3
|
+
This document describes how Agent Policy Kit (APK) is built: its modules, how data moves from the preset files to the native files, and why one package version is one configuration release. It is for maintainers who change the code. For the files that APK writes per assistant, see [assistants](../reference/assistants.md). For receipts and transactions, see [ownership](../reference/ownership.md).
|
|
4
|
+
|
|
5
|
+
## Design rules
|
|
6
|
+
|
|
7
|
+
- APK runs only when a person or an agent starts a configuration command. It detects the installed command-line tools, reads the requested preferences, writes native files and exits.
|
|
8
|
+
- APK adds no hook, proxy, launcher, plugin, daemon, runtime audit or background updater. A native client never imports or starts APK.
|
|
9
|
+
- Generated native files contain no reference to the npm package, the source checkout or the APK state directory. They keep working after the package is removed.
|
|
10
|
+
- The role files and routing instructions apply only when the main agent decides to delegate. APK keeps the main model and does not enable a disabled subagent feature.
|
|
11
|
+
|
|
12
|
+
## One version is one configuration release
|
|
13
|
+
|
|
14
|
+
The `version` field in `package.json` identifies one configuration release. That release contains these items:
|
|
15
|
+
|
|
16
|
+
| Item | Source |
|
|
17
|
+
|---|---|
|
|
18
|
+
| Presets Light, Standard and Top-tier (ids `fast`, `balanced`, `quality`) | `policies/*.json`, labels and the top models switch in `src/release.mjs` |
|
|
19
|
+
| Model catalog snapshot | `models/catalog.json` |
|
|
20
|
+
| Role names, descriptions and prompts | `src/roles.mjs` |
|
|
21
|
+
| Native file templates and routing instructions | `src/native.mjs` |
|
|
22
|
+
| Preferences validation | `src/policy.mjs`, `schema/policy.schema.json` |
|
|
23
|
+
| Command codec | `src/explicit.mjs` |
|
|
24
|
+
| Release notes | `CHANGELOG.md` |
|
|
25
|
+
| Configuration page | `site/index.html`, generated from the items above |
|
|
26
|
+
|
|
27
|
+
There is no second version number for presets or for the catalog. A change to any of these items needs a new package version. [Release](release.md) explains why the host build enforces this rule.
|
|
28
|
+
|
|
29
|
+
## Modules
|
|
30
|
+
|
|
31
|
+
| Module | Responsibility |
|
|
32
|
+
|---|---|
|
|
33
|
+
| `bin/agent-policy.mjs` | Parses the command line, selects the input mode, writes temporary preferences for `--config` and explicit arguments, and prints JSON or readable text |
|
|
34
|
+
| `src/detect.mjs` | Finds each assistant's executable on `PATH`, at known locations and, on macOS, in the ChatGPT Desktop and Claude Desktop bundles. It confirms identity from `--version` and, for Kimi and Gemini, from `--help` |
|
|
35
|
+
| `src/policy.mjs` | Validates preferences: schema version, limits 1 to 32, selected roles, model identifiers, efforts that the catalog allows, avoid lists |
|
|
36
|
+
| `src/roles.mjs` | Defines the six roles. The page and native generation use the same definitions |
|
|
37
|
+
| `src/release.mjs` | Exposes the package version, the presets, the catalog and the release notes |
|
|
38
|
+
| `src/explicit.mjs` | Converts explicit tool arguments to preferences (CLI) and preferences to a command (page) |
|
|
39
|
+
| `src/share.mjs` | Encodes and decodes the page form state in the URL fragment |
|
|
40
|
+
| `src/native.mjs` | Renders role files and the instruction block for each assistant, and gives the native paths |
|
|
41
|
+
| `src/install.mjs` | Plans, applies, inspects and removes owned changes in transactions, and writes receipts |
|
|
42
|
+
| `src/toml.mjs` | Reads and edits TOML values through the one runtime dependency, `toml-eslint-parser` |
|
|
43
|
+
| `src/setup.mjs` | Runs detection, then plans and applies for each selected client in sequence, and collects per-client results |
|
|
44
|
+
| `src/inspect.mjs` | Reads current user-level subagent settings for `show`, without writes and without starting executables |
|
|
45
|
+
| `src/output.mjs` | Formats readable terminal output. Captured output stays JSON |
|
|
46
|
+
|
|
47
|
+
The CLI needs no compilation step. Only the configuration page is generated.
|
|
48
|
+
|
|
49
|
+
## Data flow for a setup command
|
|
50
|
+
|
|
51
|
+
1. `bin/agent-policy.mjs` accepts one input mode: explicit tool arguments, `--release` with an optional `--preset`, `--config`, or `--policy`. A combination of modes fails with `CONFLICTING_OPTIONS`.
|
|
52
|
+
2. The CLI converts the input to preferences and validates them with `validatePolicy`. Explicit arguments always contain a complete map of selected roles. The required `code` and `light` fields copy the first selected role, and the complete map overrides them.
|
|
53
|
+
3. `setupDetected` in `src/setup.mjs` detects the clients. Only clients that the preferences list are selected.
|
|
54
|
+
4. For each selected and detected client, `planInstall` builds a plan from the native templates. Without `--apply`, the plan is the result.
|
|
55
|
+
5. With `--apply`, `applyInstall` commits the plan in a transaction and writes the receipt. Plans and transactions run one client at a time, because one transaction can change shared state that the next plan reads.
|
|
56
|
+
6. The result has one entry per client. One client can fail while another succeeds.
|
|
57
|
+
|
|
58
|
+
The first selected role in role-definition order (`src/roles.mjs`) supplies the native default subagent. An effort of `null` means no explicit pin. [Roles](../reference/roles.md) documents the per-assistant details.
|
|
59
|
+
|
|
60
|
+
## Data flow for the configuration page
|
|
61
|
+
|
|
62
|
+
1. `npm run build:site` runs `scripts/build-site.mjs`.
|
|
63
|
+
2. The script embeds the release data, the presets, the catalog, the role definitions, `src/explicit.mjs`, `src/share.mjs`, `site/base.css`, the font and the limit illustration into `site/template.html`.
|
|
64
|
+
3. The result is one self-contained file, `site/index.html`. It needs no backend and sends no request to compose a command.
|
|
65
|
+
4. The page always writes the full explicit command, also when a preset filled the form. The CLI validates the command again.
|
|
66
|
+
|
|
67
|
+
[Website](website.md) covers the page build and the hosted copy.
|
|
68
|
+
|
|
69
|
+
## Ownership in short
|
|
70
|
+
|
|
71
|
+
Receipt format v4 stores the selected roles, bounded ownership snapshots and the applied release, source and preset. Receipts are the applied truth. `policy.json` in the state directory is only the latest requested snapshot. A replacement virtually undoes the owned changes to the original user values, renders the target and commits against the current file contents. Removal restores the original user values and keeps unrelated later edits. [Ownership](../reference/ownership.md) is the canonical description.
|
|
@@ -0,0 +1,93 @@
|
|
|
1
|
+
# Development
|
|
2
|
+
|
|
3
|
+
This document tells maintainers and contributors how to set up the repository, run the checks and tests, enable the pre-push hook, and meet the sandbox requirement of the package tests. For the module structure, see [architecture](architecture.md).
|
|
4
|
+
|
|
5
|
+
## Requirements
|
|
6
|
+
|
|
7
|
+
- Node.js 22.x (22.13 or later) or 24 and later. The `engines` field in `package.json` sets this range.
|
|
8
|
+
- npm.
|
|
9
|
+
- For the package tests: `sandbox-exec` on macOS or bubblewrap (`bwrap`) on Linux.
|
|
10
|
+
|
|
11
|
+
The CLI has no build step. Only the configuration page is generated.
|
|
12
|
+
|
|
13
|
+
## Set up a clone
|
|
14
|
+
|
|
15
|
+
1. Install the dependencies without lifecycle scripts:
|
|
16
|
+
|
|
17
|
+
```sh
|
|
18
|
+
npm ci --ignore-scripts --no-audit --no-fund
|
|
19
|
+
```
|
|
20
|
+
|
|
21
|
+
2. Prime the dependency cache for the offline package tests:
|
|
22
|
+
|
|
23
|
+
```sh
|
|
24
|
+
npm run test:cache
|
|
25
|
+
```
|
|
26
|
+
|
|
27
|
+
3. Enable the pre-push hook once per clone:
|
|
28
|
+
|
|
29
|
+
```sh
|
|
30
|
+
git config core.hooksPath .githooks
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
`npm run test:cache` installs the dependencies into a temporary directory and removes it after. On a new machine, `npm ci` can cache the tarballs without the registry metadata that a separate offline consumer needs. This step adds that metadata.
|
|
34
|
+
|
|
35
|
+
## Checks and tests
|
|
36
|
+
|
|
37
|
+
| Command | What it does |
|
|
38
|
+
|---|---|
|
|
39
|
+
| `npm run check` | Validates `policies/balanced.json`, checks the JavaScript syntax in `src/`, `bin/` and `scripts/`, rejects a stale `site/index.html`, and inspects the package contents |
|
|
40
|
+
| `npm run test:unit` | Runs every test file whose name does not contain `package` |
|
|
41
|
+
| `npm run test:package` | Runs the installed-tarball tests (`test/*package*.test.mjs`) |
|
|
42
|
+
| `npm test` | Runs all tests, unit and package |
|
|
43
|
+
| `npm run build:site` | Regenerates `site/index.html` |
|
|
44
|
+
|
|
45
|
+
`npm run check` also rejects package files that are larger than 1 MiB, test files, archives, private folders, user home paths and token-like strings. It checks that every relative link in a packaged Markdown file points to a packaged file. For this reason, packaged documents do not link to `scripts/`, `test/`, `.github/` or `.githooks/`. Write those paths as code.
|
|
46
|
+
|
|
47
|
+
Run `npm run build:site` after a change to the page template, `site/base.css`, the role definitions, the command codec, the version, the presets, the catalog or the changelog.
|
|
48
|
+
|
|
49
|
+
## Package tests and the sandbox
|
|
50
|
+
|
|
51
|
+
The package tests pack the real tarball, install it in a temporary consumer and run it with access to the source checkout denied. They use `sandbox-exec` on macOS and bubblewrap on Linux. If neither is available, the tests fail. They never skip.
|
|
52
|
+
|
|
53
|
+
A managed sandbox can forbid a nested sandbox. In that case, run the package tests on a normal host that the owner approves.
|
|
54
|
+
|
|
55
|
+
The package tests also check these results:
|
|
56
|
+
|
|
57
|
+
- Setup works with the package, the source and the state removed after setup, and standalone consumers still read the native files.
|
|
58
|
+
- Two synthetic versions upgrade and downgrade changed models and templates safely. A synthetic version is a test fixture, not a release.
|
|
59
|
+
|
|
60
|
+
Consumer fixtures read files. They do not prove that a native client loads the files or that a model runs.
|
|
61
|
+
|
|
62
|
+
## Test environment
|
|
63
|
+
|
|
64
|
+
- Use temporary home directories. Do not touch the real home directory.
|
|
65
|
+
- Detection looks for desktop app bundles in `/Applications`. Set `AGENT_POLICY_APPLICATIONS_DIR` to another absolute directory to replace it. The tests set this variable, so apps on the host do not change the results.
|
|
66
|
+
- `AGENT_POLICY_HOME` sets the state directory. The [ownership reference](../reference/ownership.md#state-directory) gives the selection order and the default.
|
|
67
|
+
- Keep the existing checks for transactions, the complete read set, rollback, ownership, symbolic links and privacy.
|
|
68
|
+
|
|
69
|
+
## Pre-push hook
|
|
70
|
+
|
|
71
|
+
`.githooks/pre-push` runs `npm run check` and `npm run test:unit` before each push that updates a branch or a tag. A push that only deletes refs skips both. The hook stops with a message if `node_modules` is missing.
|
|
72
|
+
|
|
73
|
+
The hook is not packaged. It is a contributor check and has no relation to the settings that APK generates.
|
|
74
|
+
|
|
75
|
+
## Continuous integration
|
|
76
|
+
|
|
77
|
+
| Workflow | Trigger | Jobs |
|
|
78
|
+
|---|---|---|
|
|
79
|
+
| Verify package (`ci.yml`) | Every push and pull request | `test` on macOS with Node 22.13.0 and on Ubuntu 22.04 with Node 24 runs `npm run test:cache`, `npm run check` and `npm test`. `site-build` runs after `test`. When the version has a `v` tag, it builds the hosted site and checks the upload with a Wrangler dry run, without credentials |
|
|
80
|
+
| Lint (`lint.yml`) | Pull requests and pushes to `main` | `Lint` runs `npm run check` |
|
|
81
|
+
| Deploy configurator (`deploy-site.yml`) | After Verify package, or manual | See [website](website.md) |
|
|
82
|
+
|
|
83
|
+
The `main` ruleset requires the `Lint` check.
|
|
84
|
+
|
|
85
|
+
## What not to add
|
|
86
|
+
|
|
87
|
+
Do not add hooks, wrappers, plugins, daemons, runtime audits or package paths to generated settings. Receipts and backups belong only to configuration operations.
|
|
88
|
+
|
|
89
|
+
## Related documents
|
|
90
|
+
|
|
91
|
+
- [Release](release.md): prepare and publish a configuration release.
|
|
92
|
+
- [Verification](verification.md): the evidence record for each release.
|
|
93
|
+
- [Assistants](../reference/assistants.md): native files and limits per assistant.
|