instar 1.3.85 → 1.3.87
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/commands/init.js +1 -1
- 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 +16 -6
- package/dist/core/PostUpdateMigrator.js.map +1 -1
- package/dist/scaffold/templates.js +2 -2
- package/dist/scaffold/templates.js.map +1 -1
- package/dist/server/CapabilityIndex.js +2 -2
- package/dist/server/CapabilityIndex.js.map +1 -1
- package/dist/server/attentionApi.d.ts +6 -0
- package/dist/server/attentionApi.d.ts.map +1 -0
- package/dist/server/attentionApi.js +68 -0
- package/dist/server/attentionApi.js.map +1 -0
- package/dist/server/routes.d.ts.map +1 -1
- package/dist/server/routes.js +13 -9
- package/dist/server/routes.js.map +1 -1
- package/package.json +1 -1
- package/src/data/builtin-manifest.json +62 -62
- package/src/scaffold/templates.ts +2 -2
- package/upgrades/0.9.15.md +1 -1
- package/upgrades/1.3.85.md +13 -13
- package/upgrades/1.3.86.md +29 -0
- package/upgrades/1.3.87.md +30 -0
- package/upgrades/side-effects/attention-api-vocabulary-compatibility.md +126 -0
- package/upgrades/side-effects/commitments-agent-contract-vocabulary.md +39 -0
- package/upgrades/side-effects/external-operation-action-vocabulary.md +132 -0
|
@@ -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,126 @@
|
|
|
1
|
+
# Side-Effects Review — Attention API vocabulary compatibility
|
|
2
|
+
|
|
3
|
+
**Version / slug:** `attention-api-vocabulary-compatibility`
|
|
4
|
+
**Date:** `2026-05-29`
|
|
5
|
+
**Author:** `instar-codey`
|
|
6
|
+
**Second-pass reviewer:** `self-audit; subagent not spawned by tool policy`
|
|
7
|
+
|
|
8
|
+
## Summary of the change
|
|
9
|
+
|
|
10
|
+
This change adds a route-boundary normalizer for Attention Queue status and
|
|
11
|
+
priority vocabulary. Canonical read/store values stay uppercase, while write
|
|
12
|
+
requests may use documented aliases such as `resolved`, `medium`, `body`, and
|
|
13
|
+
`source`. Generated guidance is also corrected to show the required stable item
|
|
14
|
+
id. Files touched include `src/server/attentionApi.ts`, `src/server/routes.ts`,
|
|
15
|
+
the generated guidance templates, and unit/integration/e2e tests.
|
|
16
|
+
|
|
17
|
+
## Decision-point inventory
|
|
18
|
+
|
|
19
|
+
- `PATCH /attention/:id` — modified — accepts documented aliases before calling
|
|
20
|
+
the existing status updater.
|
|
21
|
+
- `GET /attention?status=...` — modified — accepts status aliases for filtering.
|
|
22
|
+
- `POST /attention` — modified — accepts documented create-field aliases before
|
|
23
|
+
the existing tone-gated create path.
|
|
24
|
+
- Attention topic-flood guard — pass-through — no threshold, coalescing, or
|
|
25
|
+
topic creation behavior is changed.
|
|
26
|
+
|
|
27
|
+
---
|
|
28
|
+
|
|
29
|
+
## 1. Over-block
|
|
30
|
+
|
|
31
|
+
The change reduces rejection of legitimate documented request shapes. It does
|
|
32
|
+
not add new block conditions. Unknown statuses and priorities still reject on
|
|
33
|
+
write, which is appropriate because the server cannot safely infer arbitrary
|
|
34
|
+
lifecycle states.
|
|
35
|
+
|
|
36
|
+
---
|
|
37
|
+
|
|
38
|
+
## 2. Under-block
|
|
39
|
+
|
|
40
|
+
The alias layer broadens accepted write vocabulary. The main residual risk is an
|
|
41
|
+
operator using an ambiguous word outside the alias set; those values still
|
|
42
|
+
reject. The accepted aliases map only to existing canonical values, so no new
|
|
43
|
+
state can bypass lifecycle handling.
|
|
44
|
+
|
|
45
|
+
---
|
|
46
|
+
|
|
47
|
+
## 3. Level-of-abstraction fit
|
|
48
|
+
|
|
49
|
+
The fix belongs at the HTTP route boundary. Internal storage and Telegram topic
|
|
50
|
+
commands already use canonical statuses; external callers and generated
|
|
51
|
+
guidance use friendlier names. Normalizing at the boundary preserves internal
|
|
52
|
+
consistency without forcing every caller to know storage vocabulary.
|
|
53
|
+
|
|
54
|
+
---
|
|
55
|
+
|
|
56
|
+
## 4. Signal vs authority compliance
|
|
57
|
+
|
|
58
|
+
**Required reference:** [docs/signal-vs-authority.md](../../docs/signal-vs-authority.md)
|
|
59
|
+
|
|
60
|
+
- [ ] No — this change produces a signal consumed by an existing smart gate.
|
|
61
|
+
- [ ] No — this change has no block/allow surface.
|
|
62
|
+
- [x] Yes — but this is hard-invariant API validation over a finite enum.
|
|
63
|
+
- [ ] Yes, with brittle logic — STOP. Reshape the design.
|
|
64
|
+
|
|
65
|
+
This is not a judgment gate. The route validates and normalizes finite API enum
|
|
66
|
+
values, which is one of the hard-invariant validation cases allowed by the
|
|
67
|
+
principle. It does not inspect message meaning or add a new block authority.
|
|
68
|
+
|
|
69
|
+
---
|
|
70
|
+
|
|
71
|
+
## 5. Interactions
|
|
72
|
+
|
|
73
|
+
- **Shadowing:** The normalizer runs before existing `updateAttentionStatus` and
|
|
74
|
+
`createAttentionItem` calls. Canonical values pass through unchanged.
|
|
75
|
+
- **Double-fire:** No additional Telegram send, topic creation, callback, or
|
|
76
|
+
persistence path is added.
|
|
77
|
+
- **Races:** No shared mutable state is introduced; normalization is pure.
|
|
78
|
+
- **Feedback loops:** Internal release-readiness resolution calls that already
|
|
79
|
+
send `resolved` now work against the route instead of failing.
|
|
80
|
+
|
|
81
|
+
---
|
|
82
|
+
|
|
83
|
+
## 6. External surfaces
|
|
84
|
+
|
|
85
|
+
The `/attention` write surface becomes more permissive for documented aliases.
|
|
86
|
+
The read surface remains canonical uppercase. Generated AGENTS/CLAUDE guidance
|
|
87
|
+
will include a stable `id` in new installs and migrations. No existing attention
|
|
88
|
+
state is rewritten. No new attention items are created by the verification path.
|
|
89
|
+
|
|
90
|
+
---
|
|
91
|
+
|
|
92
|
+
## 7. Rollback cost
|
|
93
|
+
|
|
94
|
+
Rollback is a normal hot-fix revert. There is no data migration. If reverted,
|
|
95
|
+
documented lowercase resolve calls and create aliases would fail again until a
|
|
96
|
+
replacement patch lands.
|
|
97
|
+
|
|
98
|
+
---
|
|
99
|
+
|
|
100
|
+
## Conclusion
|
|
101
|
+
|
|
102
|
+
The fix aligns the documented write vocabulary with the canonical read/store
|
|
103
|
+
vocabulary without changing topic creation policy or existing state. The
|
|
104
|
+
three-tier tests cover the compatibility path and keep the topic-facing effects
|
|
105
|
+
stubbed during verification.
|
|
106
|
+
|
|
107
|
+
---
|
|
108
|
+
|
|
109
|
+
## Second-pass review (if required)
|
|
110
|
+
|
|
111
|
+
**Reviewer:** `self-audit; subagent not spawned by tool policy`
|
|
112
|
+
**Independent read of the artifact: concur**
|
|
113
|
+
|
|
114
|
+
The compatibility layer is intentionally limited to finite enum and field-name
|
|
115
|
+
aliases. It does not create automatic item ids, because stable ids are part of
|
|
116
|
+
the queue's dedupe discipline; the docs now show that requirement explicitly.
|
|
117
|
+
|
|
118
|
+
---
|
|
119
|
+
|
|
120
|
+
## Evidence pointers
|
|
121
|
+
|
|
122
|
+
- Read-only live inspection found 9 existing attention items using statuses
|
|
123
|
+
`OPEN` and `DONE`, priorities `HIGH` and `NORMAL`, and no suppressed-topic log
|
|
124
|
+
present.
|
|
125
|
+
- Focused verification:
|
|
126
|
+
`npx vitest run tests/unit/attention-api-normalization.test.ts tests/integration/attention-route-vocabulary.test.ts tests/e2e/attention-queue-vocabulary-lifecycle.test.ts tests/unit/SeedMigration.test.ts`
|
|
@@ -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`
|