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.
@@ -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`