instar 1.3.86 → 1.3.88
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/dist/core/FeatureDefinitions.js +1 -1
- package/dist/core/FeatureDefinitions.js.map +1 -1
- package/dist/core/PostUpdateMigrator.d.ts.map +1 -1
- package/dist/core/PostUpdateMigrator.js +15 -5
- package/dist/core/PostUpdateMigrator.js.map +1 -1
- package/dist/scaffold/templates.js +1 -1
- package/dist/scaffold/templates.js.map +1 -1
- package/dist/server/AgentServer.d.ts +2 -0
- package/dist/server/AgentServer.d.ts.map +1 -1
- package/dist/server/AgentServer.js +27 -2
- package/dist/server/AgentServer.js.map +1 -1
- package/dist/server/CapabilityIndex.js +2 -2
- package/dist/server/CapabilityIndex.js.map +1 -1
- package/package.json +1 -1
- package/src/data/builtin-manifest.json +19 -19
- package/src/scaffold/templates.ts +1 -1
- package/upgrades/0.9.15.md +1 -1
- package/upgrades/1.3.85.md +13 -13
- package/upgrades/1.3.87.md +30 -0
- package/upgrades/1.3.88.md +30 -0
- package/upgrades/side-effects/commitments-agent-contract-vocabulary.md +39 -0
- package/upgrades/side-effects/external-operation-action-vocabulary.md +132 -0
- package/upgrades/side-effects/mentor-config-hot-read.md +103 -0
|
@@ -1,8 +1,8 @@
|
|
|
1
1
|
{
|
|
2
2
|
"$schema": "./builtin-manifest.schema.json",
|
|
3
3
|
"schemaVersion": 1,
|
|
4
|
-
"generatedAt": "2026-05-
|
|
5
|
-
"instarVersion": "1.3.
|
|
4
|
+
"generatedAt": "2026-05-29T13:03:58.977Z",
|
|
5
|
+
"instarVersion": "1.3.88",
|
|
6
6
|
"entryCount": 193,
|
|
7
7
|
"entries": {
|
|
8
8
|
"hook:session-start": {
|
|
@@ -11,7 +11,7 @@
|
|
|
11
11
|
"domain": "identity",
|
|
12
12
|
"sourcePath": "src/core/PostUpdateMigrator.ts",
|
|
13
13
|
"installedPath": ".instar/hooks/instar/session-start.sh",
|
|
14
|
-
"contentHash": "
|
|
14
|
+
"contentHash": "1fd1742471085a3b4ea20557d99aee966ea8bc4d92582b51cf18791ce76429d3",
|
|
15
15
|
"since": "2025-01-01"
|
|
16
16
|
},
|
|
17
17
|
"hook:dangerous-command-guard": {
|
|
@@ -20,7 +20,7 @@
|
|
|
20
20
|
"domain": "safety",
|
|
21
21
|
"sourcePath": "src/core/PostUpdateMigrator.ts",
|
|
22
22
|
"installedPath": ".instar/hooks/instar/dangerous-command-guard.sh",
|
|
23
|
-
"contentHash": "
|
|
23
|
+
"contentHash": "1fd1742471085a3b4ea20557d99aee966ea8bc4d92582b51cf18791ce76429d3",
|
|
24
24
|
"since": "2025-01-01"
|
|
25
25
|
},
|
|
26
26
|
"hook:grounding-before-messaging": {
|
|
@@ -29,7 +29,7 @@
|
|
|
29
29
|
"domain": "safety",
|
|
30
30
|
"sourcePath": "src/core/PostUpdateMigrator.ts",
|
|
31
31
|
"installedPath": ".instar/hooks/instar/grounding-before-messaging.sh",
|
|
32
|
-
"contentHash": "
|
|
32
|
+
"contentHash": "1fd1742471085a3b4ea20557d99aee966ea8bc4d92582b51cf18791ce76429d3",
|
|
33
33
|
"since": "2025-01-01"
|
|
34
34
|
},
|
|
35
35
|
"hook:compaction-recovery": {
|
|
@@ -38,7 +38,7 @@
|
|
|
38
38
|
"domain": "identity",
|
|
39
39
|
"sourcePath": "src/core/PostUpdateMigrator.ts",
|
|
40
40
|
"installedPath": ".instar/hooks/instar/compaction-recovery.sh",
|
|
41
|
-
"contentHash": "
|
|
41
|
+
"contentHash": "1fd1742471085a3b4ea20557d99aee966ea8bc4d92582b51cf18791ce76429d3",
|
|
42
42
|
"since": "2025-01-01"
|
|
43
43
|
},
|
|
44
44
|
"hook:external-operation-gate": {
|
|
@@ -47,7 +47,7 @@
|
|
|
47
47
|
"domain": "safety",
|
|
48
48
|
"sourcePath": "src/core/PostUpdateMigrator.ts",
|
|
49
49
|
"installedPath": ".instar/hooks/instar/external-operation-gate.js",
|
|
50
|
-
"contentHash": "
|
|
50
|
+
"contentHash": "1fd1742471085a3b4ea20557d99aee966ea8bc4d92582b51cf18791ce76429d3",
|
|
51
51
|
"since": "2025-01-01"
|
|
52
52
|
},
|
|
53
53
|
"hook:deferral-detector": {
|
|
@@ -56,7 +56,7 @@
|
|
|
56
56
|
"domain": "safety",
|
|
57
57
|
"sourcePath": "src/core/PostUpdateMigrator.ts",
|
|
58
58
|
"installedPath": ".instar/hooks/instar/deferral-detector.js",
|
|
59
|
-
"contentHash": "
|
|
59
|
+
"contentHash": "1fd1742471085a3b4ea20557d99aee966ea8bc4d92582b51cf18791ce76429d3",
|
|
60
60
|
"since": "2025-01-01"
|
|
61
61
|
},
|
|
62
62
|
"hook:post-action-reflection": {
|
|
@@ -65,7 +65,7 @@
|
|
|
65
65
|
"domain": "evolution",
|
|
66
66
|
"sourcePath": "src/core/PostUpdateMigrator.ts",
|
|
67
67
|
"installedPath": ".instar/hooks/instar/post-action-reflection.js",
|
|
68
|
-
"contentHash": "
|
|
68
|
+
"contentHash": "1fd1742471085a3b4ea20557d99aee966ea8bc4d92582b51cf18791ce76429d3",
|
|
69
69
|
"since": "2025-01-01"
|
|
70
70
|
},
|
|
71
71
|
"hook:external-communication-guard": {
|
|
@@ -74,7 +74,7 @@
|
|
|
74
74
|
"domain": "safety",
|
|
75
75
|
"sourcePath": "src/core/PostUpdateMigrator.ts",
|
|
76
76
|
"installedPath": ".instar/hooks/instar/external-communication-guard.js",
|
|
77
|
-
"contentHash": "
|
|
77
|
+
"contentHash": "1fd1742471085a3b4ea20557d99aee966ea8bc4d92582b51cf18791ce76429d3",
|
|
78
78
|
"since": "2025-01-01"
|
|
79
79
|
},
|
|
80
80
|
"hook:scope-coherence-collector": {
|
|
@@ -83,7 +83,7 @@
|
|
|
83
83
|
"domain": "coherence",
|
|
84
84
|
"sourcePath": "src/core/PostUpdateMigrator.ts",
|
|
85
85
|
"installedPath": ".instar/hooks/instar/scope-coherence-collector.js",
|
|
86
|
-
"contentHash": "
|
|
86
|
+
"contentHash": "1fd1742471085a3b4ea20557d99aee966ea8bc4d92582b51cf18791ce76429d3",
|
|
87
87
|
"since": "2025-01-01"
|
|
88
88
|
},
|
|
89
89
|
"hook:scope-coherence-checkpoint": {
|
|
@@ -92,7 +92,7 @@
|
|
|
92
92
|
"domain": "coherence",
|
|
93
93
|
"sourcePath": "src/core/PostUpdateMigrator.ts",
|
|
94
94
|
"installedPath": ".instar/hooks/instar/scope-coherence-checkpoint.js",
|
|
95
|
-
"contentHash": "
|
|
95
|
+
"contentHash": "1fd1742471085a3b4ea20557d99aee966ea8bc4d92582b51cf18791ce76429d3",
|
|
96
96
|
"since": "2025-01-01"
|
|
97
97
|
},
|
|
98
98
|
"hook:free-text-guard": {
|
|
@@ -101,7 +101,7 @@
|
|
|
101
101
|
"domain": "safety",
|
|
102
102
|
"sourcePath": "src/core/PostUpdateMigrator.ts",
|
|
103
103
|
"installedPath": ".instar/hooks/instar/free-text-guard.sh",
|
|
104
|
-
"contentHash": "
|
|
104
|
+
"contentHash": "1fd1742471085a3b4ea20557d99aee966ea8bc4d92582b51cf18791ce76429d3",
|
|
105
105
|
"since": "2025-01-01"
|
|
106
106
|
},
|
|
107
107
|
"hook:claim-intercept": {
|
|
@@ -110,7 +110,7 @@
|
|
|
110
110
|
"domain": "coherence",
|
|
111
111
|
"sourcePath": "src/core/PostUpdateMigrator.ts",
|
|
112
112
|
"installedPath": ".instar/hooks/instar/claim-intercept.js",
|
|
113
|
-
"contentHash": "
|
|
113
|
+
"contentHash": "1fd1742471085a3b4ea20557d99aee966ea8bc4d92582b51cf18791ce76429d3",
|
|
114
114
|
"since": "2025-01-01"
|
|
115
115
|
},
|
|
116
116
|
"hook:claim-intercept-response": {
|
|
@@ -119,7 +119,7 @@
|
|
|
119
119
|
"domain": "coherence",
|
|
120
120
|
"sourcePath": "src/core/PostUpdateMigrator.ts",
|
|
121
121
|
"installedPath": ".instar/hooks/instar/claim-intercept-response.js",
|
|
122
|
-
"contentHash": "
|
|
122
|
+
"contentHash": "1fd1742471085a3b4ea20557d99aee966ea8bc4d92582b51cf18791ce76429d3",
|
|
123
123
|
"since": "2025-01-01"
|
|
124
124
|
},
|
|
125
125
|
"hook:stop-gate-router": {
|
|
@@ -128,7 +128,7 @@
|
|
|
128
128
|
"domain": "safety",
|
|
129
129
|
"sourcePath": "src/core/PostUpdateMigrator.ts",
|
|
130
130
|
"installedPath": ".instar/hooks/instar/stop-gate-router.js",
|
|
131
|
-
"contentHash": "
|
|
131
|
+
"contentHash": "1fd1742471085a3b4ea20557d99aee966ea8bc4d92582b51cf18791ce76429d3",
|
|
132
132
|
"since": "2025-01-01"
|
|
133
133
|
},
|
|
134
134
|
"hook:auto-approve-permissions": {
|
|
@@ -137,7 +137,7 @@
|
|
|
137
137
|
"domain": "safety",
|
|
138
138
|
"sourcePath": "src/core/PostUpdateMigrator.ts",
|
|
139
139
|
"installedPath": ".instar/hooks/instar/auto-approve-permissions.js",
|
|
140
|
-
"contentHash": "
|
|
140
|
+
"contentHash": "1fd1742471085a3b4ea20557d99aee966ea8bc4d92582b51cf18791ce76429d3",
|
|
141
141
|
"since": "2025-01-01"
|
|
142
142
|
},
|
|
143
143
|
"job:health-check": {
|
|
@@ -1457,7 +1457,7 @@
|
|
|
1457
1457
|
"type": "subsystem",
|
|
1458
1458
|
"domain": "server",
|
|
1459
1459
|
"sourcePath": "src/server/AgentServer.ts",
|
|
1460
|
-
"contentHash": "
|
|
1460
|
+
"contentHash": "58f8f59f8d94511835333083269d3c512e8916dede7cc69fcdaf3b159b7e392b",
|
|
1461
1461
|
"since": "2025-01-01"
|
|
1462
1462
|
},
|
|
1463
1463
|
"subsystem:session-manager": {
|
|
@@ -1489,7 +1489,7 @@
|
|
|
1489
1489
|
"type": "subsystem",
|
|
1490
1490
|
"domain": "updates",
|
|
1491
1491
|
"sourcePath": "src/core/PostUpdateMigrator.ts",
|
|
1492
|
-
"contentHash": "
|
|
1492
|
+
"contentHash": "1fd1742471085a3b4ea20557d99aee966ea8bc4d92582b51cf18791ce76429d3",
|
|
1493
1493
|
"since": "2025-01-01"
|
|
1494
1494
|
},
|
|
1495
1495
|
"subsystem:scheduler": {
|
|
@@ -473,7 +473,7 @@ This routes feedback to the Instar maintainers automatically. Valid types: \`bug
|
|
|
473
473
|
- **When to use** (PROACTIVE — this is the trigger): the moment a user offers to give you a credential (API key, password, token) or you realize you need one, use Secret Drop. It is the ONLY correct way to collect a secret. NEVER accept it pasted into Telegram or chat, and NEVER create a local file (e.g. \`.instar/secrets/foo.env\`) and ask the user to edit/paste into it — that defeats the one-time, in-memory, never-on-disk guarantee and asks the user to edit files (which you must never do). Always issue a Secret Drop one-time link instead.
|
|
474
474
|
|
|
475
475
|
**Commitments & Follow-Through** — Durable tracking for any promise you make to the user. When you say "I'll report back when X", "I'll check in after N minutes", or otherwise commit to a future action, register it so the follow-through survives session turnover, restarts, and compaction.
|
|
476
|
-
- Open a commitment: \`curl -X POST -H "Authorization: Bearer $AUTH" http://localhost:${port}/commitments -H 'Content-Type: application/json' -d '{"userRequest":"<what you
|
|
476
|
+
- Open a one-time follow-up commitment: \`curl -X POST -H "Authorization: Bearer $AUTH" http://localhost:${port}/commitments -H 'Content-Type: application/json' -d '{"userRequest":"<what the user asked>","agentResponse":"<what you said you would do>","type":"one-time-action","topicId":TOPIC_ID}'\`
|
|
477
477
|
- List / inspect: \`curl -H "Authorization: Bearer $AUTH" http://localhost:${port}/commitments\` · \`GET /commitments/:id\`
|
|
478
478
|
- Mark delivered when done: \`curl -X POST -H "Authorization: Bearer $AUTH" http://localhost:${port}/commitments/:id/deliver\`
|
|
479
479
|
- The PromiseBeacon fires cadenced heartbeats on open commitments so you actually follow through (and surfaces atRisk items), and the commitment-check job surfaces overdue ones.
|
package/upgrades/0.9.15.md
CHANGED
|
@@ -10,7 +10,7 @@ Now every MCP tool call passes through a safety gate:
|
|
|
10
10
|
|
|
11
11
|
1. **PreToolUse Hook** (`external-operation-gate.js`): Automatically installed in `.instar/hooks/`. Intercepts all `mcp__*` tool calls, classifies them by mutability (read/write/modify/delete) and reversibility, then calls the gate API.
|
|
12
12
|
|
|
13
|
-
2. **ExternalOperationGate**: Server-side risk evaluation. Combines the operation classification with a risk matrix to decide: `
|
|
13
|
+
2. **ExternalOperationGate**: Server-side risk evaluation. Combines the operation classification with a risk matrix to decide: `proceed`, `block`, `show-plan` (requires user approval), or `suggest-alternative`. Dangerous operations (bulk deletes, irreversible sends) require explicit user approval.
|
|
14
14
|
|
|
15
15
|
3. **MessageSentinel**: Emergency stop detection. If the user says "stop everything" or "emergency stop", the sentinel intercepts the message and halts operations immediately — before normal message routing.
|
|
16
16
|
|
package/upgrades/1.3.85.md
CHANGED
|
@@ -4,27 +4,27 @@
|
|
|
4
4
|
|
|
5
5
|
## What Changed
|
|
6
6
|
|
|
7
|
-
The
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
|
|
7
|
+
The External Operation Gate action vocabulary is now consistent across the
|
|
8
|
+
endpoint, generated hook, generated guidance, and docs. The canonical successful
|
|
9
|
+
action is `proceed`; `allow` is retained only as a legacy hook compatibility
|
|
10
|
+
alias. Unknown action values from the gate now block external write/delete MCP
|
|
11
|
+
operations instead of being permitted through fallthrough.
|
|
12
12
|
|
|
13
13
|
## What to Tell Your User
|
|
14
14
|
|
|
15
|
-
- **
|
|
15
|
+
- **External operation safety is clearer**: "When I gate an external-service action, the documented decision words now match the live evaluator. Allowed operations say proceed, risky ones ask for a plan, and malformed gate responses stop instead of slipping through."
|
|
16
16
|
|
|
17
17
|
## Summary of New Capabilities
|
|
18
18
|
|
|
19
19
|
| Capability | How to Use |
|
|
20
20
|
|-----------|-----------|
|
|
21
|
-
|
|
|
21
|
+
| External Operation Gate vocabulary alignment | Automatic for generated hooks and evaluator responses |
|
|
22
22
|
|
|
23
23
|
## Evidence
|
|
24
24
|
|
|
25
|
-
Before the change,
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
25
|
+
Before the change, live evaluation returned `proceed` while generated docs
|
|
26
|
+
described the allowed action as `allow`, and the hook accepted `proceed` only by
|
|
27
|
+
falling through unrecognized actions. After the change, focused unit tests cover
|
|
28
|
+
core vocabulary and hook behavior, integration tests cover representative
|
|
29
|
+
evaluator route outcomes, and an e2e HTTP lifecycle verifies `proceed`,
|
|
30
|
+
`show-plan`, and `block` outcomes through AgentServer.
|
|
@@ -0,0 +1,30 @@
|
|
|
1
|
+
# Upgrade Guide — vNEXT
|
|
2
|
+
|
|
3
|
+
<!-- bump: patch -->
|
|
4
|
+
|
|
5
|
+
## What Changed
|
|
6
|
+
|
|
7
|
+
Two fixes ship together here.
|
|
8
|
+
|
|
9
|
+
**Operation-safety gate action vocabulary and fail-closed hardening.** The external operation-safety gate emits a proceed action for allowed operations, but the generated guard hook and the docs described the allowed action as allow and only branched explicitly on the block, show-plan, and suggest-alternative cases — so proceed was permitted only by falling through, and an unrecognized action would slip through that same silent path. The hook now permits proceed explicitly (keeping allow for backward compatibility) and blocks any unrecognized action instead of letting it pass, and the docs and generated guidance now use the real vocabulary. This is a safety tightening: an unknown gate decision now fails closed.
|
|
10
|
+
|
|
11
|
+
**Commitments follow-up contract guidance.** The generated Commitments guidance described creating follow-up promises with a type the server actually rejects and omitted a required field. Agents now record follow-up promises as one-time-action commitments that include both the user request and the agent response before marking them delivered, matching the live contract.
|
|
12
|
+
|
|
13
|
+
## What to Tell Your User
|
|
14
|
+
|
|
15
|
+
- **The operation-safety gate is stricter now**: when I check whether an outside action is safe, an allowed action is now handled on purpose rather than by accident, and anything the safety check does not recognize is blocked rather than waved through. How existing approvals and blocks work is unchanged.
|
|
16
|
+
- **Commitment follow-through is more reliable**: when I register a future follow-up for myself, the built-in guidance now uses the same wording the server actually accepts, so the reminder can be created and closed cleanly.
|
|
17
|
+
|
|
18
|
+
## Summary of New Capabilities
|
|
19
|
+
|
|
20
|
+
| Capability | How to Use |
|
|
21
|
+
|-----------|-----------|
|
|
22
|
+
| Operation-gate fail-closed on unknown actions | Automatic. The generated operation-safety hook now blocks any unrecognized gate decision instead of permitting it, and treats the allowed action explicitly. |
|
|
23
|
+
| Operation-gate vocabulary alignment | Automatic. Docs and generated guidance now match the action values the gate actually emits. |
|
|
24
|
+
| Commitments follow-up contract guidance | Automatic for newly generated or migrated agent guidance. |
|
|
25
|
+
|
|
26
|
+
## Evidence
|
|
27
|
+
|
|
28
|
+
- Operation gate: unit (ExternalOperationGate and hook-installation), integration (operation-safety routes), and e2e (action-vocabulary lifecycle) tests cover the explicit-permit, legacy-compat, and block-unknown paths; the docs, templates, and spec were aligned to the real vocabulary.
|
|
29
|
+
- Commitments: live lifecycle verification created a test commitment, inspected it, delivered it, and verified it was terminal and closed; focused unit, integration, and e2e tests pin the accepted create payload, delivery transition, active-list closure, generated guidance, and PromiseBeacon stop behavior.
|
|
30
|
+
- Note: the operation-gate change merged to main first, but its release notes were dropped during a rebase across a release-cut, so it is released here alongside the commitments guidance fix.
|
|
@@ -0,0 +1,30 @@
|
|
|
1
|
+
# Upgrade Guide — vNEXT
|
|
2
|
+
|
|
3
|
+
<!-- bump: patch -->
|
|
4
|
+
|
|
5
|
+
## What Changed
|
|
6
|
+
|
|
7
|
+
Mentor onboarding now hot-reads the mentor settings from the agent config file
|
|
8
|
+
each time the runner checks its configuration. Updating the mentor curriculum or
|
|
9
|
+
mentor runtime settings no longer requires a full server restart. If the config
|
|
10
|
+
file is missing, unreadable, malformed, or has a malformed mentor block, the
|
|
11
|
+
runner falls back to the startup snapshot instead of throwing into a mentor tick.
|
|
12
|
+
|
|
13
|
+
## What to Tell Your User
|
|
14
|
+
|
|
15
|
+
- **Mentor settings update without a restart**: "When you adjust the mentor curriculum or related mentor settings, the running server picks them up on the next mentor check. If the config edit is malformed, the mentor keeps using its last safe startup settings instead of failing a tick."
|
|
16
|
+
|
|
17
|
+
## Summary of New Capabilities
|
|
18
|
+
|
|
19
|
+
| Capability | How to Use |
|
|
20
|
+
|-----------|------------|
|
|
21
|
+
| Mentor config hot-read | Edit mentor settings in the agent config file; the next mentor status check or tick reads the updated mentor block |
|
|
22
|
+
| Defensive mentor config fallback | Malformed config edits keep the mentor on its startup settings until the file is repaired |
|
|
23
|
+
|
|
24
|
+
## Evidence
|
|
25
|
+
|
|
26
|
+
Unit coverage proves changed on-disk mentor agendas are read on the next call
|
|
27
|
+
and malformed config falls back to the startup snapshot. Integration coverage
|
|
28
|
+
pins the mentor route to fresh runner config reads. Server-backed e2e coverage
|
|
29
|
+
proves a running AgentServer reflects mentor config edits without restart and
|
|
30
|
+
falls back safely when the config file is malformed.
|
|
@@ -0,0 +1,39 @@
|
|
|
1
|
+
# Commitments Agent Contract Vocabulary
|
|
2
|
+
|
|
3
|
+
## Scope
|
|
4
|
+
|
|
5
|
+
Align generated agent guidance with the live `/commitments` API contract for one-time follow-up promises.
|
|
6
|
+
|
|
7
|
+
## Runtime Finding
|
|
8
|
+
|
|
9
|
+
Live verification showed the lifecycle works with the actual contract:
|
|
10
|
+
|
|
11
|
+
1. Create with `type:"one-time-action"`, `userRequest`, `agentResponse`, and `topicId` returns a `pending` commitment with the expected fields.
|
|
12
|
+
2. Direct lookup returns the same record.
|
|
13
|
+
3. Delivery transitions the commitment to `delivered`, sets `resolvedAt`, increments the version, and closes it from active follow-up.
|
|
14
|
+
4. PromiseBeacon delivery behavior is already covered by integration: delivered commitments stop scheduled beacon work and later fires are no-ops.
|
|
15
|
+
|
|
16
|
+
The rejected shape was the generated guidance: `type:"follow-up"` plus no `agentResponse`.
|
|
17
|
+
|
|
18
|
+
## Files
|
|
19
|
+
|
|
20
|
+
- `src/scaffold/templates.ts` — update new-agent Commitments guidance to use `one-time-action` and include `agentResponse`.
|
|
21
|
+
- `src/core/PostUpdateMigrator.ts` — update migrated Commitments guidance for existing agents.
|
|
22
|
+
- `src/data/builtin-manifest.json` — regenerated after template guidance changes.
|
|
23
|
+
- `tests/unit/PostUpdateMigrator-secretDropHardenedRetrieve.test.ts` — pin migrated guidance vocabulary.
|
|
24
|
+
- `tests/unit/commitments-agent-guidance-contract.test.ts` — pin template and migrator vocabulary together.
|
|
25
|
+
- `tests/unit/commitment-routes.test.ts` — cover the agent-facing create shape and deliver transition.
|
|
26
|
+
- `tests/e2e/commitments-api-lifecycle.test.ts` — cover create, lookup, deliver, lookup, and active-list closure through HTTP.
|
|
27
|
+
- `docs/specs/COMMITMENTS-AGENT-CONTRACT-VOCABULARY-SPEC.md` — durable contract note.
|
|
28
|
+
- `docs/specs/COMMITMENTS-AGENT-CONTRACT-VOCABULARY-SPEC.eli16.md` — plain-language overview.
|
|
29
|
+
- `upgrades/NEXT.md` — release-note entry for the next patch.
|
|
30
|
+
|
|
31
|
+
## Side Effects
|
|
32
|
+
|
|
33
|
+
Existing agents that receive migrated guidance will be taught the accepted route contract. Existing commitment records are not migrated and no stored status vocabulary changes.
|
|
34
|
+
|
|
35
|
+
The guidance still uses "open" as a human verb. The API status for a newly created one-time follow-up remains `pending`.
|
|
36
|
+
|
|
37
|
+
## Rollback
|
|
38
|
+
|
|
39
|
+
Revert the template/migrator and tests. Runtime commitment behavior is unchanged by this PR.
|
|
@@ -0,0 +1,132 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: External Operation Gate — action vocabulary alignment
|
|
3
|
+
slug: external-operation-action-vocabulary
|
|
4
|
+
date: 2026-05-29
|
|
5
|
+
author: codey
|
|
6
|
+
second_pass_required: false
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## Summary of the change
|
|
10
|
+
|
|
11
|
+
The External Operation Gate endpoint already used `proceed` as its canonical
|
|
12
|
+
allowed action, but generated documentation described the action as `allow`, and
|
|
13
|
+
the generated PreToolUse hook accepted `proceed` only through an implicit
|
|
14
|
+
fallthrough path. This change aligns the docs and hook with the core gate:
|
|
15
|
+
`proceed`, `show-plan`, `suggest-alternative`, and `block`. The hook explicitly
|
|
16
|
+
permits `proceed`, keeps legacy `allow` compatibility, and blocks unknown action
|
|
17
|
+
values instead of silently proceeding.
|
|
18
|
+
|
|
19
|
+
Files touched include the hook generator in `PostUpdateMigrator`, generated and
|
|
20
|
+
source documentation, capability text, and unit/integration/e2e tests.
|
|
21
|
+
|
|
22
|
+
## Decision-point inventory
|
|
23
|
+
|
|
24
|
+
- `ExternalOperationGate.evaluate()` — pass-through — remains the authority and
|
|
25
|
+
source of truth for emitted action values.
|
|
26
|
+
- Generated `external-operation-gate.js` hook — modified — explicitly maps
|
|
27
|
+
`proceed` and legacy `allow` to permit; unknown actions now block.
|
|
28
|
+
- Generated/documented External Operation Safety guidance — modified — names
|
|
29
|
+
`proceed` instead of `allow`.
|
|
30
|
+
|
|
31
|
+
---
|
|
32
|
+
|
|
33
|
+
## 1. Over-block
|
|
34
|
+
|
|
35
|
+
The new over-block risk is a gate response with a valid future action value that
|
|
36
|
+
this hook version does not recognize. The hook would block it. That is
|
|
37
|
+
intentional for this trust boundary: new action values must be added to the hook
|
|
38
|
+
and tests deliberately, rather than inheriting permission through fallthrough.
|
|
39
|
+
|
|
40
|
+
Legacy `allow` is accepted to avoid over-blocking stale local test doubles or
|
|
41
|
+
older endpoints during mixed-version windows.
|
|
42
|
+
|
|
43
|
+
---
|
|
44
|
+
|
|
45
|
+
## 2. Under-block
|
|
46
|
+
|
|
47
|
+
The main previous under-block was unknown action fallthrough. That is removed.
|
|
48
|
+
The remaining under-block is the existing designed fail-open path when the local
|
|
49
|
+
server is unreachable or the hook cannot parse input. This change does not alter
|
|
50
|
+
that broader availability policy.
|
|
51
|
+
|
|
52
|
+
---
|
|
53
|
+
|
|
54
|
+
## 3. Level-of-abstraction fit
|
|
55
|
+
|
|
56
|
+
The endpoint remains the authority for operation risk. The hook is the local
|
|
57
|
+
enforcement adapter that translates action words into command behavior. Keeping
|
|
58
|
+
legacy compatibility at the hook boundary is the right layer because it protects
|
|
59
|
+
mixed-version local installs without changing the core gate's canonical type.
|
|
60
|
+
|
|
61
|
+
---
|
|
62
|
+
|
|
63
|
+
## 4. Signal vs authority compliance
|
|
64
|
+
|
|
65
|
+
**Required reference:** [docs/signal-vs-authority.md](../../docs/signal-vs-authority.md)
|
|
66
|
+
|
|
67
|
+
- [x] No — this change does not add a brittle detector with blocking authority.
|
|
68
|
+
|
|
69
|
+
The hook is already an enforcement authority at an external-service trust
|
|
70
|
+
boundary. This change narrows that authority's accepted action vocabulary to the
|
|
71
|
+
canonical gate contract, plus one explicit legacy alias. It does not introduce a
|
|
72
|
+
new heuristic signal.
|
|
73
|
+
|
|
74
|
+
---
|
|
75
|
+
|
|
76
|
+
## 5. Interactions
|
|
77
|
+
|
|
78
|
+
- **Hook install/migration:** existing installations receive the updated hook
|
|
79
|
+
when the post-update migrator refreshes built-in hook content.
|
|
80
|
+
- **Mixed versions:** a hook updated before an endpoint still accepts legacy
|
|
81
|
+
`allow`; an endpoint updated before a hook already worked because old hooks
|
|
82
|
+
fell through on `proceed`.
|
|
83
|
+
- **Identity grounding:** irreversible writes that receive `proceed` still pass
|
|
84
|
+
through the existing identity-grounding injection path before allowing the
|
|
85
|
+
operation.
|
|
86
|
+
- **Read fast path:** read MCP calls still exit locally before calling the gate.
|
|
87
|
+
|
|
88
|
+
---
|
|
89
|
+
|
|
90
|
+
## 6. External surfaces
|
|
91
|
+
|
|
92
|
+
External-service MCP calls are affected. The successful endpoint action is
|
|
93
|
+
documented as `proceed`; callers that asserted the old documentation should
|
|
94
|
+
update. The hook's runtime behavior is stricter for malformed gate responses:
|
|
95
|
+
unknown actions now block non-read external operations instead of silently
|
|
96
|
+
running them.
|
|
97
|
+
|
|
98
|
+
No persistent state schema changes, no database migrations, and no external API
|
|
99
|
+
credentials are affected.
|
|
100
|
+
|
|
101
|
+
---
|
|
102
|
+
|
|
103
|
+
## 7. Rollback cost
|
|
104
|
+
|
|
105
|
+
Pure code and docs rollback. Revert the hook generator and docs/tests; no data
|
|
106
|
+
cleanup is needed. During rollback, `proceed` would again be permitted only by
|
|
107
|
+
unknown fallthrough in the hook, which is the behavior this change removes.
|
|
108
|
+
|
|
109
|
+
---
|
|
110
|
+
|
|
111
|
+
## Conclusion
|
|
112
|
+
|
|
113
|
+
The mismatch is reconciled by treating the core gate as authoritative and
|
|
114
|
+
pinning `proceed` as the canonical allowed action. The compatibility alias keeps
|
|
115
|
+
mixed-version behavior stable, while the unknown-action block removes the
|
|
116
|
+
silent-fallthrough safety gap. Clear to ship.
|
|
117
|
+
|
|
118
|
+
---
|
|
119
|
+
|
|
120
|
+
## Second-pass review (if required)
|
|
121
|
+
|
|
122
|
+
**Reviewer:** not required
|
|
123
|
+
**Independent read of the artifact:** not required
|
|
124
|
+
|
|
125
|
+
---
|
|
126
|
+
|
|
127
|
+
## Evidence pointers
|
|
128
|
+
|
|
129
|
+
- `tests/unit/ExternalOperationGate.test.ts`
|
|
130
|
+
- `tests/unit/hook-installation.test.ts`
|
|
131
|
+
- `tests/integration/external-operation-safety-routes.test.ts`
|
|
132
|
+
- `tests/e2e/external-operation-action-vocabulary-lifecycle.test.ts`
|
|
@@ -0,0 +1,103 @@
|
|
|
1
|
+
# Side-Effects Review — Mentor config hot-read
|
|
2
|
+
|
|
3
|
+
**Version / slug:** `mentor-config-hot-read`
|
|
4
|
+
**Date:** `2026-05-29`
|
|
5
|
+
**Author:** `instar-codey`
|
|
6
|
+
**Second-pass reviewer:** `instar-codey second-pass checklist`
|
|
7
|
+
|
|
8
|
+
## Summary of the change
|
|
9
|
+
|
|
10
|
+
This change makes the mentor runner read the mentor block from the agent config
|
|
11
|
+
file each time it needs configuration. The startup mentor config is retained as
|
|
12
|
+
the fallback for missing, unreadable, or malformed config reads. This lets
|
|
13
|
+
operators adjust the mentor curriculum and runtime settings without restarting
|
|
14
|
+
the server while keeping mentor ticks defensive.
|
|
15
|
+
|
|
16
|
+
## Decision-point inventory
|
|
17
|
+
|
|
18
|
+
- `readMentorConfigFromDisk` — add — reads and merges the current on-disk mentor
|
|
19
|
+
block with defaults, or returns the startup fallback on unsafe reads.
|
|
20
|
+
- `AgentServer.buildMentorRunner` — modify — passes a fresh-reading getConfig
|
|
21
|
+
closure to the mentor runner instead of closing over startup config.
|
|
22
|
+
- Mentor route and e2e tests — modify — pin route-level and server-level hot-read
|
|
23
|
+
behavior.
|
|
24
|
+
|
|
25
|
+
---
|
|
26
|
+
|
|
27
|
+
## 1. Over-block
|
|
28
|
+
|
|
29
|
+
A malformed mentor block now falls back to the startup snapshot rather than
|
|
30
|
+
partially applying valid fields around the malformed value. That is intentional:
|
|
31
|
+
the config edit is not trustworthy enough to merge safely, and keeping the last
|
|
32
|
+
known startup behavior is less surprising than accepting a half-bad shape.
|
|
33
|
+
|
|
34
|
+
## 2. Under-block
|
|
35
|
+
|
|
36
|
+
The helper performs only shallow shape validation, matching the previous runtime
|
|
37
|
+
behavior that trusted the loaded config shape. Invalid field values inside an
|
|
38
|
+
object can still flow through. This PR does not add schema validation because the
|
|
39
|
+
request was scoped to hot-reading and defensive read failures, not changing the
|
|
40
|
+
mentor config contract.
|
|
41
|
+
|
|
42
|
+
## 3. Level-of-abstraction fit
|
|
43
|
+
|
|
44
|
+
The hot-read belongs at the `AgentServer` runner boundary, where the server
|
|
45
|
+
already wires state directory access into the mentor runner. The runner remains a
|
|
46
|
+
pure dependency-injected orchestrator and still receives a simple getConfig
|
|
47
|
+
function.
|
|
48
|
+
|
|
49
|
+
## 4. Signal vs authority compliance
|
|
50
|
+
|
|
51
|
+
**Required reference:** [docs/signal-vs-authority.md](../../docs/signal-vs-authority.md)
|
|
52
|
+
|
|
53
|
+
- [ ] No — this change produces a signal consumed by an existing smart gate.
|
|
54
|
+
- [ ] No — this change has no block/allow surface.
|
|
55
|
+
- [ ] Yes — but the logic is a smart gate with full conversational context.
|
|
56
|
+
- [x] Not applicable to conversational/product judgment — this is runtime config
|
|
57
|
+
loading for a dormant/off-by-default mentor job.
|
|
58
|
+
|
|
59
|
+
## 5. Interactions
|
|
60
|
+
|
|
61
|
+
- **Shadowing:** The helper reads only the mentor block and does not mutate the
|
|
62
|
+
main server config object.
|
|
63
|
+
- **Double-fire:** No new timers or routes are introduced; existing mentor status
|
|
64
|
+
and tick calls simply observe fresher config.
|
|
65
|
+
- **Races:** A config write racing with a mentor tick can produce a transient
|
|
66
|
+
parse failure. The fallback path handles that by using the startup snapshot.
|
|
67
|
+
- **Feedback loops:** Live mentor delivery can now observe changed topic or
|
|
68
|
+
curriculum settings without restart. Outstanding-prompt safeguards remain
|
|
69
|
+
unchanged.
|
|
70
|
+
|
|
71
|
+
## 6. External surfaces
|
|
72
|
+
|
|
73
|
+
Operators can update mentor settings while the server is running. A bad edit no
|
|
74
|
+
longer risks throwing through a mentor tick. No public API shape changes, data
|
|
75
|
+
migrations, Telegram topic creation, or dashboard changes are introduced.
|
|
76
|
+
|
|
77
|
+
## 7. Rollback cost
|
|
78
|
+
|
|
79
|
+
Rollback is a code and test revert. No persisted data is migrated or rewritten.
|
|
80
|
+
|
|
81
|
+
## Conclusion
|
|
82
|
+
|
|
83
|
+
The change addresses the stale mentor config cache directly and keeps the mentor
|
|
84
|
+
loop defensive under malformed runtime config edits. Unit, integration, and e2e
|
|
85
|
+
tests cover the hot-read and fallback behavior.
|
|
86
|
+
|
|
87
|
+
---
|
|
88
|
+
|
|
89
|
+
## Second-pass review (if required)
|
|
90
|
+
|
|
91
|
+
**Reviewer:** instar-codey second-pass checklist
|
|
92
|
+
**Independent read of the artifact:** concur
|
|
93
|
+
|
|
94
|
+
The second pass agrees that the helper is scoped to mentor config only, preserves
|
|
95
|
+
the runner abstraction, and does not introduce new authority or delivery paths.
|
|
96
|
+
|
|
97
|
+
---
|
|
98
|
+
|
|
99
|
+
## Evidence pointers
|
|
100
|
+
|
|
101
|
+
- `tests/unit/AgentServer-mentor-config-hot-read.test.ts`
|
|
102
|
+
- `tests/integration/mentor-routes.test.ts`
|
|
103
|
+
- `tests/e2e/mentor-onboarding-lifecycle.test.ts`
|